[Zope3-dev] DISCUSS: Zope3 and Zope2's version object

[Brian Lloyd]

> > Agreed.  But ZODB's "version" interface does more than locking
> > objects: it also stores modified *revisions* of the locked objects in
> > the database.  (In fact this seems the only way to lock an object.)
> > Is that really necessary?  Isn't it enough to store locking
> > informantion in the database?
> 
> It would be great if this could be the case. I notice that WebDAV locks
> currently store their locking information in seperate persistent, 
> versioned,
> objects which seems a bit wasteful to me :-S

The semantics of DAV locks are / can be very different than the 
ZODB "locking" that happens re: versions. Even if the semantics 
were basically the same (in certain case that can be true today), 
it would be a bad idea IMHO to implement DAV locks on top of an 
implementation detail of ZODB. Future versions of both DAV and 
ZODB could have reasons to change their locking behavior, and  
then we'd be in a pickle (er.. so to speak :)

Note that we have a perfect real-world example of this type of 
problem with bobobase_modification_time (a.k.a. _p_mtime from 
the ZODB). Many people really want an application-level "last 
modified" property. Long ago we made the mistake of thinking 
we could adopt _p_mtime for this, but it often turns out to 
be wrong - the semantic of an application-level last modified 
is different than that of the database modification time.


Brian Lloyd        brian@zope.com
Software Engineer  540.361.1716       
Zope Corporation   http://www.zope.com