Jim Fulton wrote:
David Pratt wrote:
There seems to be enough of a difference between Z2 and Z3 undo to have an effect on a backend like PGStorage from working on Z3. I believe the objective in the storage api is that it should not matter to the backend whether you are connected to Z2 or Z3. Can someone more familiar with the history of undo in z2 and z3 explain the current situation?

Undo has a fairly complicated API, and I can easily believe that Z2 and
Z3 call that API in very different ways.

BTW, I strongly discourage use of Undo except in emergencies.
Sadly, except when undoing the last (non-undo) transactions in
a database can lead to inconsistency.  Undo should be used with
caution and should generally not be exposed to non-expert users.

Undo has been a part of CMF and Plone for non-expert users for quite some time by exposing only the last non-undo transaction. This should be fine for Z3 I believe. In any case, my interest is initially to give Z3 what it is asking for without crapping out so contents view will work for a principal through z3 zmi.

In Z3, before bringing up the contents view, there is a check of the undo transactions for the principal. It uses z3's undo manager to getPrincipalTransactions which eventually results in a lookup in the undoLog in the external storage where it dies. Just a brief look at the undo code in z3 gives me the feeling the format

Format of what?

I am referring to is this which is the route this is taking to the undoLog :

    def _getUndoInfo(self, context, principal, first, last):
        specification = {}

        if context is not None:
            locatable = IPhysicallyLocatable(context, None)
            if locatable is not None:
                location = Prefix(locatable.getPath())
                specification.update({'location': location})

        if principal is not None:
            # TODO: The 'user' in the transactions is a concatenation
            # of 'path' and 'user' (id).  'path' used to be the path
            # of the user folder in Zope 2.  ZopePublication currently
            # does not set a path, so ZODB lets the path default to
            # '/'.  We should change ZODB3 to set no default path at
            # some point
            path = '/' # default for now
            specification.update({'user_name': path + ' ' + principal.id})

        entries = self.__db.undoInfo(first, last, specification)

It's possible that there is a bug in PGStorage in handling
extension data.  I can easily believe that Z2 doesn't use extension
data and perhaps z3 does.

Thanks. I have reported this to Shane but am also experimenting with storages so have an interest in understanding what is happening.

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to