[Zope3-dev] Changes to transaction management API

[Tim Peters]

[Garrett Smith]
>>> Recent changes to the transaction management API seem to have come
>>> out of the blue and without warning. Perhaps I missed an
>>> announcement.
>>>
>>> Are we to expect breakages of this sort on occasion?

[Jim Fulton]
>> Was there breakage? If there was, it was unintended.

[Garrett]
> IDataManager was completely restructured.

It might help (a lot) if you could be more specific, even about what
"recent" means (in "recent changes").  The only massive restructuring
I know about took place at the ZODB sprint, but I assumed you didn't
mean that since it happened a month ago.  A new beforeCommitHook
method was added a week ago, after discussion & agreement on zodb-dev
(maybe that's part of this?  ZODB changes generally don't get
discussed first on lists other than zodb-dev).  Then Jim & I made many
changes Wednesday, but they were mostly docstring rewrites, plus what
should have been _mostly_ semantically neutral minor refactoring
(IRollback got tossed then, which was not neutral).

> Anyone plugging into the transaction management facility will be broken
> by these changed.

Were _you_ burned in some specific way?  I'm not sure what "plugging
into the transaction management facility" means, concretely, but it
was sure easy to update all of the Zope (2.8) and Zope3 trunks to live
happily with the entire last month of transaction interface changes
(two spots got tripped up by the unimplemented IRollback vanishing --
that's it).  For the most part, even ZODB itself still doesn't claim
to implement its own small (but growing) collection of interfaces.

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.

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.