Hi Eshan,
Sorry for late response on this... Let me describe the problem in more
details. When committing child context's changes to parent context all
the child context's objects change their state to COMMITTED and are
flushed into the parent context without committing to database. In
parent context these objects will have persistence state NEW.
Then to the problem itself: when accessing object's relationship from
child context for objects in COMMITTED state Cayenne tries to resolve
relationship fault, RelationshipQuery is fired and routed up in context
hierarchy until it will be resolved by some of the parent contexts or if
not it will go to the top level DataChannel and will be queried from the
db. So the problem is that when we try to access some not yet faulted
relationship from child context we will end up trying to route the
relationship query up which eventually will fail since the object is not
into db yet.
Attempt to solve this was made already per CAY-1183 and the solution (or
maybe call it workaround...) was to intercept relationship queries in
top level context and if object is in persistence state NEW return empty
result since in this case we don't have valid places left to look up for
the requested relationship. This solution however doesn't work if object
was not yet committed to top level context and is in NEW state somewhere
in between top and bottom contexts. I'm thinking of possibility to
expand the CAY-1183 workaround to not top level contexts unless we will
come to some generic solution on this. But of course this will require
testing and thinking of how it may affect on current workflow...
Please fill free to ask more questions and propose your ideas on how to
deal with this.
Dima
On 07/18/2012 05:52 PM, Eshan Sudharaka wrote:
Hi,
Or should it be handle in resolveFromDB method in RelationshipFault class ?
On Wed, Jul 18, 2012 at 3:10 PM, Eshan Sudharaka <[email protected]>wrote:
Hi,
I have gone through the method invocations of this issue. As mentioned in
jira task reason for this is that the parent context is not being committed
when last statement is executing.(childMt2.getTable3();)
As I see We need handle this in BaseContext.prepareForAccess method.
Inside that we can check objectContext.hasChanges(); boolean value and if
it is false only we can continue that flow. Could you please provide me a
feed back for this approach
On Mon, Jul 16, 2012 at 5:12 PM, Andrus Adamchik <[email protected]>wrote:
Yes, the API would be the same...
But good point on usability. We had rather transparent API before, and
then replaced it with what we have now :)
The reason for this change was to avoid storing context factory and any
other stack singletons in an ObjectContext instance (be it DataContext or
CayenneContext). As ObjectContext is serializable, having lots of extra
"services" as ivars made bootstrapping it back to the stack on
deserialization a rather painful operation. So in order to streamline that
process, some of the earlier conveniences were sacrificed.
If you think of CayenneRuntime as a "factory of everything" it may not
look so confusing actually... Also maybe we can add a convenience method
CayenneRuntime.getContext(ObjectContext) to avoid a cast.
Also "getContext(DataChannel)" javadoc is mindlessly cloned from
"getContext()" without explaining the difference and needs to be fixed :)
Andrus
On Jul 16, 2012, at 2:28 PM, Dzmitry Kazimirchyk wrote:
What about next level of nesting...
ObjectContext nestedChild = runtime.getContext((DataChannel)
clientContextChild);
This approach doesn't seem handy or obvious. Is there a better way?
Dima
On 07/16/2012 02:11 PM, Andrus Adamchik wrote:
The API was refactored, but the nested contexts feature is of course
still present. Right now you'd create a client nested context using
ClientRuntime:
ClientRuntime runtime = ..
ObjectContext clientContextChild = runtime.getContext(clientContext);
Andrus
On Jul 16, 2012, at 1:00 PM, Eshan Sudharaka wrote:
Hi,
I was trying to reproduce the issue CAY-1714 and it seems that
following
operation is now invalid. (since CayenneContext has mo such method
declaration)
ObjectContext clientContext = this.clientContext.createChildContext();
So is this bug is fixed now ?
--
*~Thanks & Regards~*
***
*
Eshan
--
*~Thanks & Regards~*
***
*
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
http://esudharaka.blogspot.com/
