> I had the same questions as
> J. Merrill, and I thought through them on the drive to work
> this morning. I think that the question of how to keep
> around an edited version of something without saving it is
> really separate from persistence, unless you need to persist
> the edited version; the main need for this seems to be mainly
> in writing client-side sometimes-connected or standalone
> editor applications.
but that's a problem that's as old as software itself: data on
the screen being edited has to be written to the db (if the edit is
approved) or not (canceled).
> I don't see a problem right now with this approach:
>
> 1. Create a copy of the data in the object you wish to edit.
> This can be another instance of the same class (not
> auto-persisted), or some similar class whose instances serve
> as edited instances of other objects. So if you have a
> Person object, you may create an EditedPerson or PersonChange
> or PersonUpdate, etc. This object should probably include a
> version number of the object it was created to represent,
> unless it's a single-editor situation or the object is
> write-locked while editing.
What's auto-persistence and in that light 'not auto-persisted' ?
If these uber-vague terms without any real meaning aren't defined, this
discussion ends up being a very academic babbling between people who
don't understand the true meaning of what persistence really is. In that
light, you said "Yeah, Thomas' post was crappy." No it wasn't. It was
spot on. He clearly described what should be described.
> 2. If the user decides to quit editing, throw the edited copy
> away, and optionally write-unlock the main object.
You're not suggesting write-locking records during edits, do
you? :) How about the situation where the client crashes, the webapp is
closed by hte user, the session of the webapp is ended due to time
expiration, the client gets disconnected from the network (modem hangs
up :)) etc. ? That lock then remains. I dont' think that's a good idea.
> 3. If the user saves the changes, merge the data with the
> main object. I disagree with putting lots of functionality
> into pure data objects, for lots of good reasons, but in this
> special case I don't see a problem with the main object
> containing a Merge(EditedObject) method.
>
> Wherever the merging logic is, it can optionally check the
> supplied version number of the requested change and see if
> some other user has modified the object in the meantime (if
> the object was not write-locked).
>
> If the object WAS changed in the meantime, it can do one of
> the things normally done in these sorts of situations (often
> encountered in replication, etc.): promote one of the changes
> over the other, see if a peaceful merge is possible and
> allowed between the two changes, throw an exception, etc.
> You can also see that this approach would let you do the
> peaceful merge by tracking individual field versions; this is
> extra overhead, but probably necessary for some situations.
>
> If the object was NOT changed, it's totally okay to proceed.
> The fields of the main object can be changed and the object
> persisted. All of this is synchronized as appropriate (duh).
you just described a solution to a concurrency problem :)
To me it doesn't answer anything to 'what's transparent
persistence'.
> So what do you think of this approach? I wouldn't mind using
> an object-relational autopersistence scheme for the main
> object if it met my needs; I just haven't gotten around to
> learning how to use one yet.
you can save your time, it's not possible to do. Transparent
persistence is a vague term, automatic persistence is just as vague. :)
FB
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
