Versioning and persistence
Scott L. Burson
Thu, 22 May 1997 11:42:48 -0700 (PDT)
From: Chris Bitmead uid <firstname.lastname@example.org> (x22068)
Date: Wed, 21 May 1997 13:40:47 +1000
>That's true. I don't understand the point you're making, however. The point
>I was trying to make is that if you do it this way, you don't have to think
>about versioning on every object access, which you were pointing out would be
The point is that you would have a problem deciding how far to split
up your system in order to get some advantage out of it. If you split
too much how do keep the higher levels together? If not enough, how do
you get enough grain?
Basicly I think you were suggesting a system where you divide up the
system in a certain way into segments, and I'm questioning if that
gives you flexibility.
It's true that you lose a bit of flexibility. If two objects are in the same
segment, they will always be committed (new versions will be created) at the
But this doesn't mean you can't work with different versions of objects on a
fine-grained level. I can (in theory :-) open version 1 of a segment,
navigate down to a particular object, then open v2 of the same segment,
navigate to the corresponding object, and then compare them, or whatever I
want to do with them.
I'm not saying I know exactly how to implement this, but so far, at least, it
looks workable to me.