Re: [ZODB-Dev] Undo differences between Z2 and Z3

2006-05-19 Thread Chris Withers

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

2006-05-19 Thread Jim Fulton

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

2006-05-18 Thread Chris Withers

Jim Fulton wrote:

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.


Ah, okay.


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.


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?



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.


Indeed, and provided the transactions created by the application are 
careful to avoid problems of the above type, I think it's safe to 
provide full undo support, but the burden _is_ then on the app 
developer to make sure they do nothing unsafe when it matters.



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.


Hmmm, I guess a copy to present system, as provided in History.py, 
might well do better for application level undo...


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

2006-05-18 Thread Jim Fulton

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

2006-05-17 Thread Chris Withers

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

2006-05-17 Thread Russ Ferriday
And undo is prominently exposed in Plone, and its use is not discouraged.Do you think, Jim, that we should reconsider that?--rOn 17 May 2006, at 08:18, 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 ina 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.orghttp://mail.zope.org/mailman/listinfo/zodb-dev  —Russ FerridayTopia Systemstel: (+44) (0) 2076 177758mobile: (+44) (0) 7789 338868web: http://www.topia.comskype: ferriday ___
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

2006-05-17 Thread Jim Fulton

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

2006-05-17 Thread David Binger


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

2006-05-16 Thread Jim Fulton

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

2006-05-16 Thread David Pratt

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

2006-05-16 Thread David Pratt
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