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 : Sun Dec 01 2002 - 20:25:56 EST