weird behaviour with commit?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

weird behaviour with commit?

Tomi N/A
Hi everyone,

I do something along the following lines:

x= dc.createAndRegisterNewObject(MyClass.class);

y.setSomeProperty("newValue");
y.setToMyClass(x);
dc.commitChanges();

The problem is that "x" isn't linked with "o" after doing the commit so
at the moment I improvise doing

x = dc.createAndRegisterNewObject(MyClass.class);
dc.commitChanges();  // this commit makes the y.setToMyClass(x) work
like intended

y.setSomeProperty("newValue");
y.setToMyClass(x);
dc.commitChanges();

This is a fairly ugly hack, acceptible, but I'd like to avoid it.
Is this the intended cayenne behaviour or is it the result of using a
not-yet-stable version (1.2b4)? I'm using MSSQL, jtds 1.0...I don't know
if anything else is relevant.

Also, while I'm on topic: commitChanges() is a transactive operation -
right?

Thanks in advance,
Tomislav

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: weird behaviour with commit?

Mike Kienenberger-2
Hefest <[hidden email]> wrote:

> Hi everyone,
>
> I do something along the following lines:
>
> x= dc.createAndRegisterNewObject(MyClass.class);
>
> y.setSomeProperty("newValue");
> y.setToMyClass(x);
> dc.commitChanges();
>
> The problem is that "x" isn't linked with "o" after doing the commit so
> at the moment I improvise doing
>
> x = dc.createAndRegisterNewObject(MyClass.class);
> dc.commitChanges();  // this commit makes the y.setToMyClass(x) work
> like intended
>
> y.setSomeProperty("newValue");
> y.setToMyClass(x);
> dc.commitChanges();

Do you have both y and x in the same dc?
Probably not.   By default, y.setToMyClass(x) will try to convert x to y's
dc if they are not the same.
Since x is only a temporary object until it's committed, it probably won't
survive the conversion.

Try using:

x = y.getDataContext().createAndRegisterNewObject(MyClass.class);
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: weird behaviour with commit?

Tomi N/A
Mike Kienenberger wrote:

>Hefest <[hidden email]> wrote:
>  
>
>>Hi everyone,
>>
>>I do something along the following lines:
>>
>>x= dc.createAndRegisterNewObject(MyClass.class);
>>
>>y.setSomeProperty("newValue");
>>y.setToMyClass(x);
>>dc.commitChanges();
>>
>>The problem is that "x" isn't linked with "o" after doing the commit so
>>at the moment I improvise doing
>>
>>x = dc.createAndRegisterNewObject(MyClass.class);
>>dc.commitChanges();  // this commit makes the y.setToMyClass(x) work
>>like intended
>>
>>y.setSomeProperty("newValue");
>>y.setToMyClass(x);
>>dc.commitChanges();
>>    
>>
>
>Do you have both y and x in the same dc?
>Probably not.   By default, y.setToMyClass(x) will try to convert x to y's
>dc if they are not the same.
>Since x is only a temporary object until it's committed, it probably won't
>survive the conversion.
>
>Try using:
>
>x = y.getDataContext().createAndRegisterNewObject(MyClass.class);
>  
>
I wish it were that simple: I'm working on a (tapestry) web application
and my DataContext is stored in the session so there is, in reality,
only one (per client): I haven't initialized any other.

Btw, I initialize it like so:

    public DataContext getContext() {
        if (context == null) {
            context = Configuration.getSharedConfiguration().getDomain(
                    "MyDomain").createDataContext();
        }
        return context;
    }

I reference this context from all the pages in the application.
I don't think this is the problem as it works just fine in several other
applications I've written.
Any other ideas?

Tomislav
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: weird behaviour with commit?

nirvdrum
In reply to this post by Mike Kienenberger-2
Mike Kienenberger wrote:

> Do you have both y and x in the same dc?
> Probably not.   By default, y.setToMyClass(x) will try to convert x to y's
> dc if they are not the same.
> Since x is only a temporary object until it's committed, it probably won't
> survive the conversion.
>
> Try using:
>
> x = y.getDataContext().createAndRegisterNewObject(MyClass.class);

Actually, it's even easier than that.  If y is already registered with a
data context, there's no need to explicitly register x.

x = new MyClass();
y.setToMyClass(x);

This will auto-register x with y's data context.

--
Kevin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: weird behaviour with commit?

Mike Kienenberger-2
In reply to this post by Tomi N/A
Hefest <[hidden email]> wrote:
> I wish it were that simple: I'm working on a (tapestry) web application
> and my DataContext is stored in the session so there is, in reality,
> only one (per client): I haven't initialized any other.

It doesn't hurt to verify that it's really the case.   Put in some debugging
code and make sure that they are the same data context.

> Any other ideas?

If it's not caused by the above, then you'll have to step through the code
in the debugger and track down what's going wrong.

-Mike
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: weird behaviour with commit?

Tomi N/A
Mike Kienenberger wrote:

>Hefest <[hidden email]> wrote:
>  
>
>>I wish it were that simple: I'm working on a (tapestry) web application
>>and my DataContext is stored in the session so there is, in reality,
>>only one (per client): I haven't initialized any other.
>>    
>>
>It doesn't hurt to verify that it's really the case.   Put in some debugging
>code and make sure that they are the same data context.
>  
>
You're right, of course. I checked and both objects' getDataContext()
returns the same context.

>>Any other ideas?
>>    
>>
>If it's not caused by the above, then you'll have to step through the code
>in the debugger and track down what's going wrong.
>  
>
I've tried that, too, and if found a possible source of the
problem...has to do with using different versions of modeler (1.2b4) and
cayenne classes (<1.2b4): I'll look into it and let everyone know.

Cheers,
Tomislav

Loading...