[ZODB-Dev] Re: another reason to stop supporting versions

[Jim Fulton]

On Apr 24, 2007, at 5:01 PM, Jim Fulton wrote:



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 inconsistent data in connections.


An argument for keeping version in the past was that they  
worked.  Well, I think they don't work and I'm not interested in  
writing the test to fix them.  Is anyone else?


I will write the necessary tests to fix the undo bug.


Oh and I'm pretty sure that transactional undo doesn't handle undo of  
transactions that touch versions correctly.  This runs pretty deep  
because the storage API implementations don't return enough  
information to handle versions.  The undo method returns a  
transaction id and a sequence of object ids, but it should return a  
sequence of object-id/version pairs.


Jim

--
Jim Fulton  mailto:[EMAIL PROTECTED]Python 
Powered!
CTO (540) 361-1714  
http://www.python.org
Zope Corporationhttp://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] Re: another reason to stop supporting versions

[Gary Poster]

I assume you are more interested in seeing if you can get someone to  
raise a compelling -1 than in hearing a chorus of +1s.  But FWIW, +1  
in getting rid of versions.  It sounds like it would simplify the  
code significantly, which would be its own feature.


Gary
___
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