2/3 do look interesting, but not really something I want to get into
right now. Maybe later.
The functionality we will be needing (or rather, that is convenient), is
option 4. Option 5 also may come into play at some stage (dunno yet..
will see).
So, I started down the path of Option 4. All goes well, until one
little snag. There will be a solution (probably more than one
solution), but I'm keen on some feedback as to a "clean" way to do it:
toMany relationships.
The trivial way to implement revert is to nuke (unregister) any inserted
objects, and refresh deleted objects and modified objects from snapshots
(deleted objects will then be back in "committed" state). However,
objects which have only had a toMany relationship modified will not show
up in the Modified list, because they've not had any "attributes"
modified. Refreshing such toMany relationships is not difficult (create
a fresh ToManyList, just like refreshObjectWithSnapshot does).
Identifying which toMany lists need reverting is not so easy
Options that I can see:
1) Add a Set of modifiedRelationships to CayenneDataObject, and have the
DataContext interrogate the DataObjects to see what's changed. However,
this API would need to be defined on DataObject... seems a little messy
to add to that interface, and perhaps a bit memory hungry during large
scale modifications.
2) Another Persistence state (MODIFIED_TOMANY_RELATIONSHIPS). An object
enters this state if a toMany relationship is modified when it's in
COMMITTED state. Any other type of modifications push it to the
MODIFIED state. This seems like a very specialized state, and seems to
me to be pushing the PersistenceState concept a little bit far, but is
less memory intensive than the first option.
3) Just use the MODIFIED state for when toMany relationships are
touched, and catch an object in such a condition during commit (so as
not to actually perform the commit). I think there may even already be
a test for such a situation (where the object is marked MODIFIED, but
has no differences from the snapshot). However, this bastardizes (I
like that word for some strange reason) the MODIFIED persistence state a
little.
Any other ideas?
Thanks,
Craig
On Mon, 2002-12-02 at 14:26, Andrus wrote:
> Holger outlined this pretty well. Since as of now we do not have nested
> DataContexts, this should be straightforward (short of throwing out an
> instance of DataContext :-)).
>
> (1) is achieved by existing "invalidateObject" method.
>
> (2), (3) I would like to have such functionality, but it seems like it is
> more trouble to implement and with the web-oriented world doesn't seem all
> that common. Of course this will be extremely valuable for the
> client-server GUI apps. In any event, if there is a feeling that we need
> that, I would suggest to externalize it from DataContext or DataObject by
> creating UndoManager-like delegate. I don't remember how it worked either,
> but I would imagine that all we need to store is a history of property
> value changes per object.
>
> (4) take a look at SnapshotManager. "refreshObjectWithSnapshot" should be
> able to handle revert operation, though it is used for very specific
> purposes right now and we may discover some holes when using it in other
> places.
>
> (5) should be easy (kind of "invalidate all objects")
>
>
> Andrus
>
>
> At 05:29 AM 12/1/2002 +0100, Holger Hoffstätte wrote:
> >Craig Miskell wrote:
> > > It is becoming apparent that we will be needing rollback/revert
> > > functionality in DataContext. I'm happy to do so, but would be
> > > interested if anyone has previously given any thought to this and how it
> > > might be attacked.
> >
> >I haven't thought much about it yet, but agree it would be nice to have;
> >if you can do it because you need it, all the better. Off the top of my
> >head I think it would be nice to be able to:
> > - zap a single object back into snapshot/proxy (hollow) state
> > - undo the last n edits of a single object
> > - undo the last n operations on a DataContext
> > - revert all inserted/updated/deleted objects of a DataContext
> > - revert all fetched objects of a DataContext
> >
> >Hmm..some of this looks suspiciously familiar. :-)
> >First one should be easy, I think it's already in there?
> >Second one would obviously work through the setters, but might quickly
> >become a memory hog and needs configurable undo queue size per ObjEntity.
> >Third and fourth one look easy: just iterate over the respective ObjectIds
> >and throw them out of the change set or plaster the snapshots over the
> >objects. On second thought this could get tricky if e.g. a new object is
> >inserted, set as another object's toOne target, and then just removed from
> >the insertedObjects set - dangling reference. I cannot remember what
> >NSUndoManager does in this case.
> >Last one is probably the easiest, just zap all non-hollow (what's the
> >word, committed?) objects like in the first case.
> >
> >-h
>
This archive was generated by hypermail 2.0.0 : Mon Dec 02 2002 - 17:04:07 EST