[ZODB-Dev] CMS on top of ZODB

[Dieter Maurer]

Hi Tino,

Tino Wildenhain wrote at 2003-4-9 09:07 +0200:
 > >   *  Versioning/History
 > > ....
 > > What do you think about the prospects of these extensions?
 > 
 > There are several people who got the same idea, including myself. :)
 > A short while ago there was a short thread about this.
 > 
 > 
 > > 
 > > 
 > > I can make extensions to ZODB (with respect to programming skills
 > > and employment contract obligations) and donate them back to the core,
 > > when you are interested...
 > 
 > I'm extraordinary interested. Can I provide support in any way?

I started implementing it.

What is there so far:

  *  Patch to provide "Snapshot" transaction isolation level
     for ZODB (called "ReadCommited" patch, because I did not
     know that there is a special term for this kind of level).

     To be found on my Zope page.

  *  "HCFileStorage", a history controllable FileStorage

     To be found on my Zope page.

  *  A concept for "HistoricalReference" objects.
     Such objects will prevent deletion of
     (directly or indirectly) referenced historical versions.

     Not yet documented electronically

  *  An improved "Historical" implementation which can provide
     historical information also for objects with subobjects.

     To be found in the mailing list archive (of "zope-cmf", I think).

As you may know, my Zope page is at

  <http://www.dieter.handshake.de/pyprojects/zope>


What can you do:

  Checkout what you find interesting and provide feedback.

  There is one known bug in the "ReadCommitted" patch:
  You may get an "AttributeError" in "Transaction.begin"
  (when the transaction was used for error handling in an
  earlier request). In fact, this is a Zope bug, just triggered
  by the patch. I will fix it soon (probaly on the week end).

 > I think, the version object should have a map (dictinary) which
 > points to a list of specific historic versions of several other
 > objects. This would appear to be identical to "tagging" objects
 > in the CVS. One special subobject of this version-dispatcher
 > could in turn hold a "checkout-rule" for each tag. Subobject,
 > because it would have its own historic pile.

I do it differently:

  I have implemented a "HistoricalConnection" which loads state
  as current at a specified time. Thus, you read the object
  including its subobjects (and subsub, ...) at of this time.

 > so the way would go: 
 > userobject(permission_to_view_current)->versiondispatcher->[list/tree of 
 > all "HEAD" objects (pass -thru)] -> object by path/id
 > 
 > userobject(permission_to_view_published)->versiondispathcer->checkout-rule-obj->"published" 
 > -> (only tagged objects) -> versiondispatcher [list/tree of all historic 
 > versions] -> object by path/id
 > 
 > It looks like the versiondispatcher would be kind of a Catalog then ;)

I leveraged the existing "Historical" code.
This splits history into two components:

  *  determine which (historical) versions are available

  *  access a given version


Dieter