[Zope3-dev] Re: Version control of ZOPE3 objects

Pjotr Prins pjotr2006 at thebird.nl
Mon Jul 10 04:15:20 EDT 2006


Thanks Tres for the reply. It really helps.

I agree transactions are a problem. If SVN fails there is no clear
route to notify the user. On the other hand we merely would use it for
'historic' storage - a one way system for moving objects. As we have
to have a queue anyway, on failure an object should not be removed
from the queue. That allows the administrator to resolve the SVN
problem and rerun the queue. 

BTW I think there are two ways to make a queue - through the
filesystem (like the mailer does), or through ZODB - accessing the
queue through XML/RPC on a separate thread. If anyone knows how to use
ZODB from an independent thread outside ZOPE I am all ears. I would
like to drop the XML/RPC.

You made me think of an alternative approach though. I don't know how
you resolved your content repositories, but how about mirroring a site
into a versioned repository in ZODB. When we have a site with objects
we could create a versioned site with versioned objects (inheriting
security per object):

ZODB:

mysite:
  objectA
	objectB
	etc.

mysite_versioned:
  objectA_00001
	objectA_00002
	objectA_00003
	objectB_00001
	objectB_00002
	etc.

An XML/RPC interface could be created to store the versioned objects
offline - as objectA and objectB - through an external command. That
would allow an admin to do that through a CRON job with feedback on
the transaction. It could also purge old objects.

The nice thing is that I can quite easily create a view of older
objects in mysite_versioned (all XML/XSLT with xParrot) and even do a
simple diff, indeed.  Recovery is straightforward too. 

What do you think?

Pj.



More information about the Zope3-dev mailing list