On Wed, 14 Apr 2004, Kapil Thangavelu wrote:

> 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?

By my understanding, outside the storage, different versions are
completely independent.  You could even simulate multiple databases using
versions.  It is the storage that knows how to create new versions, merge
versions, and prevent objects being used in a version from being changed.

Mounted databases try to use the same version as the root connection.

To merge a catalog, you could bring one of the stored catalogs to life
within the storage and replay the sequence of transactions that occurred
in the other catalog.  This could be tricky, and opening a catalog within
a ZEO server would make the ZEO server less stable.

I think there might be other ways to look at it.  One way to simplify
would be to put catalogs in their own storage, separated from the content
they index.  That way, you could (ab)use the transaction machinery to
abort or commit indexes as you see fit within the catalog conflict
resolver.  I've experimented with this before, and it seemed promising.


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

Reply via email to