Jim Fulton wrote at 2007-4-24 17:01 -0400:
>I'm 99.9% sure that version commit and abort are broken in ZODB.DB.
>The commit methods in CommitVersion, and AbortVersion (and
>TransactionalUndo) call invalidate on the databse too soon -- before
>the transaction has committed. This can have a n
On 4/25/07, Christian Theune <[EMAIL PROTECTED]> wrote:
We have to tell people what to do before the next update of Zope that
includes this change so they do not get locked out of existing data.
1. Keep a backup if the ZODB before upgrading.
2. (Optional) Don't use versions.
There, done! :-)
Hi,
Am Dienstag, den 24.04.2007, 17:01 -0400 schrieb Jim Fulton:
> I'm 99.9% sure that version commit and abort are broken in ZODB.DB.
> The commit methods in CommitVersion, and AbortVersion (and
> TransactionalUndo) call invalidate on the databse too soon -- before
> the transaction has co
[Alan Runyan]
+1 for removing versions. they have been considered "bad practice" for
over 3 years.
I believe 100% its ok to remove them.
Jim "formally announce[d] the intention to deprecate versions in both
Zope and ZODB" nearly 3 years ago, here:
http://mail.zope.org/pipermail/zope3-dev/20
+1 for removing versions. they have been considered "bad practice" for
over 3 years.
I believe 100% its ok to remove them.
alan
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@z
I'm 99.9% sure that version commit and abort are broken in ZODB.DB.
The commit methods in CommitVersion, and AbortVersion (and
TransactionalUndo) call invalidate on the databse too soon -- before
the transaction has committed. This can have a number of bad
effects, including causing inc
