[Garrett] >>> IDataManager was completely restructured. [Garrett] > This was not accurate -- the restructuring happened a while ago and I > didn't catch it. I assumed this change was made along with the one I > list below.
OK, that helps a bit. Thanks! [Tim] >> If you don't have specific breakage to report, then I'm afraid I'm not >> going to take a lesson from this, cuz I just don't know what you mean >> here. [Garrent] > Change 29961 -- I was using the 'savepoint' function What 'savepoint' function? No such function was removed (not in 29961, nor in any other revision). While ZODB eventually intends to support savepoint/rollback (maybe even in time for ZODB 3.4b1), no version to date has done so. Unfortunately, ZODB 3.4 inherited some broken interfaces from the long-dead ZODB4 project appearing to _claim_ support for some subset of savepoint/rollback. There's still a partly broken `DataManagerAdapter` class too in the transaction package, trying to adapt abandonned ZODB4-style transactions to reality. > along with NoSavepointSupportRollback, which disappeared. Yes, that came along with getting rid of IRollback, and IRollback was implemented in ZODB only by NoSavepointSupportRollback. The implementation there just raised NotImplementedError. Since there was no plan to ever repair the broken stuff inherited from ZODB4, it made a lot more sense to get rid of it than to keep it around plain useless. It's unfortunate you were tempted into using the experimental ZODB4 transaction gimmicks. Maybe we need to stuff this crap back in again, despite that it's usless (the only thing actually implemented was an elaborate way of raising NotImplementedError) and misleading (because the ZODB4 scheme will never be implemented)? I don't know, but it sure isn't attractive. >> As a pragmatic matter, I'd avoid even importing the interfaces defined >> in ZODB, because they're still so inadequate and crude (as above, even >> ZODB mostly ignores them now). ZODB was a very late starter in the >> interface game, and there's not enough resource to play intense >> "interface catchup" in that project -- this gets poked at in slow >> motion, by forcing it briefly from time to time at the expense of more >> urgent ZODB tasks. > I don't think this has anything to do with the ZODB. It does: the transaction package is external (to Zope3) code, and comes from the ZODB project. That wasn't new in ZODB 3.3 or 3.4, BTW -- transactions are a database concept, and the core implementation of transactions has always come from ZODB. Everything you've talked about here so far is ZODB's code. _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com