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):
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?
Zope3-dev mailing list