Hi Scott,
First, I hope you are working with the latest CVS or nightly build
version. I committed quiet a few bug fixes related to refreshing logic
recently. (I assume you are, since to-one relationships weren't refreshed
properly just recently).
In 1.1 we indeed plan to create a same-VM/cross-VM updates, and things
should become a bit different and more memory efficient (e.g. snapshots
will be shared inside VM, etc.). I started some design work on that, I
hope to get back to it around September (unless others get ahead of me):
http://objectstyle.org/cayenne/lists/cayenne-devel/2003/06/0014.html
For now I think "refetchObject()" should be changed to refresh to-many,
just like you said. My view is that this method is appropriate for public
use (and is kind of an analogue of invalidate...only not "lazy"). So I'll
work on that.
I wouldn't change "mergeObjectWithSnapshot" though. First this method
should be considered internal to Cayenne and shouldn't be called directly
in most cases. Second, it will degrade performance of Cayenne
significantly. If users *want* to refresh to-many on all objects returned
from the query, using prefetching on to-many should do the trick.
Andrus
> I have read the relevant threads btw. I saw Holger's post re: a
> DataContextMonitor and understand how it applies. I was still concerned
> about the "expected" behavior of DataContext.refetchObject() and the
> exclusion of -to-many relationships when snapshots are updated during
> the normal course of operations.
>
> -----Original Message-----
> From: Scott Finnerty [mailto:scot..odefuey.com]
> Sent: Tuesday, July 08, 2003 2:19 PM
> To: cayenne-deve..bjectstyle.org
> Subject: Expected behavior questions
>
> I was testing a scenario in a web application where two users/sessions
> (and therefore separate DataContexts) were editing the same object. In
> both sessions I would cause the object to be retrieved from the database
> - along with its -to-many relationships. Then in one session I would
> perform an update of the object - committing the changes to the
> database. In the other session I would start an update and see the
> changes made in the other session - only to attributes (and after
> studying the code, it looks like -to-one relationships would be updated
> as well). Thus, any changes made to -to-many relationships were not
> reflected in the other session. This seems to be due to the indirection
> used for -to-many relationships (i.e., ToManyList). The ToManyList is
> established when an object is passed through
> SnapshotManager.refreshObjectWithSnapshot() which is only when the
> object's state is HOLLOW. During subsequent mergeObjectWithSnapshot()
> calls, attributes and -to-one relationships are updated - but the
> -to-many lists are not re-initialized. So if in one session changes are
> made to an object's -to-many relationships, other sessions that have
> already populated their copy of the object's -to-many relationships will
> never see the changes without specific intervention in the code. I can
> understand why for performance ToManyLists are lazy-initialized and not
> refetched on each access. However, because some parts of an object have
> been updated, it appears to allow inconsistency to creep into a
> DataContext's in-memory snapshot vs. what's in the database.
>
> The only way to force an update of an object's -to-many relationships is
> to invalidate the object (DataContext.invalidateObject()). A call to
> DataContext.refetchObject() won't do it alone.
>
> I'd like for each DataContext to stay internally consistent - if any
> part of an object is updated from the database, all aspects of the
> object are updated (or at least reset to be updated in a lazy fashion).
>
> Should DataContext.refetchObject() include "resetting" the ToManyLists
> (i.e., ToManyList.needsFetch() == true)?
>
> Should SnapshotManager.mergeObjectWithSnapshot() also "reset" the
> ToManyLists?
>
> Will the work being done on 1.1 address these issues by
> communicating/propagating "dirty" state to other DataContexts?
>
> Thanks,
> Scott Finnerty
This archive was generated by hypermail 2.0.0 : Tue Jul 08 2003 - 17:00:07 EDT