Re: [ZODB-Dev] Undo differences between Z2 and Z3
Jim Fulton wrote: Chris Withers wrote: Jim Fulton wrote: Even if you did track reads, how would you distinguish an unsafe read as above from a normal read that shouldn't cause a conflict? A write (or the undo of a write) would conflict with any reads in later transactions. Wouldn't that, in effect, make just about all transactions conflict? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Undo differences between Z2 and Z3
Chris Withers wrote: Jim Fulton wrote: Chris Withers wrote: Jim Fulton wrote: Even if you did track reads, how would you distinguish an unsafe read as above from a normal read that shouldn't cause a conflict? A write (or the undo of a write) would conflict with any reads in later transactions. Wouldn't that, in effect, make just about all transactions conflict? Possibly. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Undo differences between Z2 and Z3
Chris Withers wrote: Jim Fulton wrote: ... Even if you did track reads, how would you distinguish an unsafe read as above from a normal read that shouldn't cause a conflict? A write (or the undo of a write) would conflict with any reads in later transactions. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Undo differences between Z2 and Z3
Hi Jim, Jim Fulton wrote: 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. What sort of inconsistencies are you referring to? Undo can be a very attractive feature although usually hamstrung by catalog tie-in with Zope 2. I was hoping to look at ways of getting back some of this functionality when it came to Zope 3... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Undo differences between Z2 and Z3
Chris Withers wrote: Hi Jim, Jim Fulton wrote: 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. What sort of inconsistencies are you referring to? Logical inconsistencies. Consider two transactions, T1 and T2 that run the same code: def f(): if 'x' not in somefolder: somefolder['x'] = 42 The postcondition of the transaction is that somefolder has an item named 'x' with the value 42. Now, when T2 runs, it doesn't add the item to the folder, because T1 added it. We can undo T2 without problem. If we undo T1 without undoing T2, we do have a problem. Our current system doesn't detect the coflict between T2 and T1 because T2 read the folder but didn't write it. We don't track reads, so we don't recognize the conflict. Russ Ferriday wrote: And undo is prominently exposed in Plone, and its use is not discouraged. Do you think, Jim, that we should reconsider that? It was claimed earlier in this thread, that plone only lets you undo the most recent transactions. If this is true, then that should not be a problem. A facility that let you only undo last transactions would be safe. It would also be useful, at least for single-user systems. (Note that definition of last gets a little tricky in the presense of transactional undo.) I would hazard to guess that most transactions don't have the sort of problems mentioned above. The problem is that there isn't currently a good way to separate the problem transaction from the non-problem ones. Ther are many situations where the benefits of undo outweight the risks, which is why I still favor making it available as an adminstrative feature. It's possible that, in the future, we will provide an option of recording both data read and data written in a transaction. Then we could make undo safe. For now, the issue is mostly moot, since in most applications, transactions you want to undo tend to conflict with later ones, even with the limited conflict detection we use now. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Undo differences between Z2 and Z3
On May 17, 2006, at 6:54 AM, Jim Fulton wrote: It was claimed earlier in this thread, that plone only lets you undo the most recent transactions. If this is true, then that should not be a problem. A facility that let you only undo last transactions would be safe. It would also be useful, at least for single-user systems. (Note that definition of last gets a little tricky in the presense of transactional undo.) I would say that the undo the last transaction would be useful for all systems, but safe only for systems where all writing comes from one user. ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Undo differences between Z2 and Z3
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. 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? between z2 and z3 may be incompatible which may be the problem. The relevant portion of the traceback I receive is this: File /usr/local/zope3/z3trunk/src/zope/tales/expressions.py, line 199, in _eval return ob() File /usr/local/zope3/z3trunk/src/zope/app/publisher/browser/viewmeta.py, line 419, in __call__ return meth(*a, **k) File /usr/local/zope3/z3trunk/src/zope/app/undo/browser.py, line 33, in principalLastTransactionIsUndo last=1) File /usr/local/zope3/z3trunk/src/zope/app/undo/__init__.py, line 108, in getPrincipalTransactions return self._getUndoInfo(context, principal, first, last) File /usr/local/zope3/z3trunk/src/zope/app/undo/__init__.py, line 129, in _getUndoInfo entries = self.__db.undoInfo(first, last, specification) File /usr/local/zope3/z3trunk/src/ZODB/UndoLogCompatible.py, line 37, in undoInfo return self.undoLog(first, last, filter) File /usr/local/zope3/z3trunk/src/ZODB/PGStorage/pgstorage.py, line 478, in undoLog d.update(cPickle.loads(ext)) You should report this to Shane. 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. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Undo differences between Z2 and Z3
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.
Regards,
David
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Undo differences between Z2 and Z3
Hi Jim. I managed to fix this by modifying the storage but it seems to me strange to differentiate in a storage whether it is a backend to a z2 or z3 app. Regards, David ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
