>>> IDataManager was completely restructured.
> 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!
>> 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
> 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
> 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
>> 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