Hi!
http://svn.zope.org/?view=revrev=30334 changed the behavior of
undoInfo() in a way that is not backwards compatible. See
http://www.zope.org/Collectors/Zope/1822 for details.
I can see 3 ways to resolve this:
1.) restoring the old behavior of undoInfo() in ZODB
2.) restoring the old
Please see:
http://www.zope.org/Wikis/DevSite/Projects/Zope2.8/MilestonePlan
-aj
pgpFGEDVzQK2D.pgp
Description: PGP signature
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML
[yuppie]
http://svn.zope.org/?view=revrev=30334 changed the behavior of
undoInfo() in a way that is not backwards compatible.
That's true, or at least off-by-one different than recent ZODB 3.2s.
Rev 30334 fixed two bugs in the implementation, so that the behavior
matched what the documentation
Hi!
Tim Peters wrote:
[yuppie]
http://svn.zope.org/?view=revrev=30334 changed the behavior of
undoInfo() in a way that is not backwards compatible.
That's true, or at least off-by-one different than recent ZODB 3.2s.
Rev 30334 fixed two bugs in the implementation, so that the behavior
[yuppie]
...
Don't know what other people think. I believe restoring the old undoInfo
behavior and adjusting the documentation would be the best solution.
Fixing this in undoable_transactions would fork the behavior of both
methods and fixing all products that depend on the old behavior would
Tim Peters wrote:
[yuppie]
...
Don't know what other people think. I believe restoring the old undoInfo
behavior and adjusting the documentation would be the best solution.
Fixing this in undoable_transactions would fork the behavior of both
methods and fixing all products that depend on the
[yuppie]
...
These are the two use cases I'm aware of. Both only use last 0 and
both expect slicing behavior for positive values, e.g. these conditions
should be True if we don't change undoable_transactions::
db.undoInfo(0, 20) == db.undoInfo(0, 99)[0:20]
db.undoInfo(20, 40) ==
