[ZODB-Dev] Possible compatibility problem.

[Tim Peters]

[Lennart Regebro]
> WingDBG does this: tx = get_transaction().sub()
> That fails because 'Transaction' object has not attribute 'sub'. This
> is obviously an effect of the moving from subtransactions to
> checkpoints.

Nope, it's not.  It's a consequence of just moving beyond ZODB 3.2. 
Transactions in ZODB 3.3 and 3.4 have never had a .sub() method
(that's been true for over a year).  A transaction object in ZODB 3.2
does have an undocumented sub() method, but as far as I can tell it's
never used by ZODB or by any Zope >= 2.7.

> transaction.get() has the same effect, btw.

Doesn't look like that's true.  This is the code in ZODB 3.2's Transaction.py:

    def sub(self):
        # Create a manually managed subtransaction for internal use
        r=self.__class__()
        r.user=self.user
        r.description=self.description
        r._extension=self._extension
        return r

So sub() created a brand new transaction object in ZODB 3.2, but
copied over self's meta-data.  transaction.get() doesn't do that;
transaction.get() in 3.4 is like get_transaction() in 3.2, returning
the current thread's transaction, and creating a new transaction
object only if the current thread doesn't already have one.  sub()
always created a new transaction object, and didn't pay any attention
to threads; I don't know why the code comment above said
"subtransaction", since the code in sub() clearly has nothing to do
with ZODB subtransactions.

Since I can't find any uses, I don't know why someone would try
calling sub(); in any case, there's nothing exactly like it after ZODB
3.2.

> Question: Is it Zope2.8 that is wrong or WingDBG?

WingDBG used an undocumented method and got burned when it went away. 
I don't know why they used it.  If there's a compelling use case,
sub() could be added to ZODB 3.4; offhand I don't see a compelling use
case.