On Wed, 14 Apr 2004 06:59:05 -0400
Kapil Thangavelu <[EMAIL PROTECTED]> wrote:

> On Tue, 2004-04-13 at 12:01, Shane Hathaway wrote:
> > On Tue, 13 Apr 2004, Kapil Thangavelu wrote:
> > 
> > > since
> > > objects modified in a version are in essence locked from
> > > participating in other transactions, actions like modifying
> > > content in a version in a cmf site amounts to locking the catalog
> > > from changes outside of the version, which amounts to shutting
> > > down write activities to a cmf site.
> > 
> > This is only true of FileStorage.  Some other storage could
> > implement ZODB versions with merging capability rather than locking.
> > 
> 
> good point, just because hasn't been doesn't mean it can't ;-)
> 
> although i wonder if there is some hand waving in progress here that i
> can't see. i guess my semantic notion of versions has been that of
> long lived transactions, and is there a better means of thinking of
> them? how do they play across with multiple mounted zodbs? what would
> something like merge mean in the context of a catalog?

Catalogs are actually fairly easy to handle, at least in theory. The
state of the catalog directly depends (and is derived from) the current
state of the cataloged objects. So merging the catalog should mean:
merge the content first and then reindex it.

>From this pov, it would be possible to get cataloging right in the
current version machinery as well. This machinery would need to allow
objects to override the locking behavior in some way. In the case of the
catalog it would be fine for a current catalog and the one in the
version to ignore each other (i.e., changing the one in the version does
not lock the current one). Then when the version is saved/merged, the
affected objects are recataloged.

In practical terms this would mean that the versioned catalog would need
to keep track of the uids that had been cataloged, uncataloged and
reindexed in the version. The "merge" would mean cataloging,
uncataloging and reindexing those same uids in the current catalog.

-Casey


_______________________________________________
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to