[Zodb-checkins] SVN: ZODB/branches/3.3/ Officially deprecate
Transaction.begin().
Tim Peters
tim.one at comcast.net
Thu Sep 9 23:25:47 EDT 2004
Log message for revision 27488:
Officially deprecate Transaction.begin().
Changed:
U ZODB/branches/3.3/NEWS.txt
U ZODB/branches/3.3/src/ZODB/tests/testZODB.py
U ZODB/branches/3.3/src/transaction/_transaction.py
-=-
Modified: ZODB/branches/3.3/NEWS.txt
===================================================================
--- ZODB/branches/3.3/NEWS.txt 2004-09-10 01:46:02 UTC (rev 27487)
+++ ZODB/branches/3.3/NEWS.txt 2004-09-10 03:25:47 UTC (rev 27488)
@@ -5,14 +5,14 @@
Connection
----------
-ZODB intends to raise ConnnectionStateError if an attempt is made to
-close a connection while modifications are pending (the connection is
-involved in a transaction that hasn't been abort()'ed or commit()'ed).
-It was missing the case where the only pending modifications were made
-in subtransactions. This has been fixed. If an attempt to close a
-connection with pending subtransactions is made now,
+ZODB intends to raise ConnnectionStateError if an attempt is made to close
+a connection while modifications are pending (the connection is involved in
+a transaction that hasn't been ``abort()``'ed or ``commit()``'ed). It was
+missing the case where the only pending modifications were made in
+subtransactions. This has been fixed. If an attempt to close a connection
+with pending subtransactions is made now::
- ``ConnnectionStateError: Cannot close a connection with a pending subtransaction``
+ ConnnectionStateError: Cannot close a connection with a pending subtransaction
is raised.
@@ -29,22 +29,39 @@
that ZODB intends to prevent committing a transaction in which a
ReadConflictError occurred; this was an obscure case it missed.
-- Growing pains: ZODB 3.1 and 3.2 had a bug wherein ``Transaction.begin()``
- didn't abort the current transaction if the only pending changes were in a
- subtransaction. In ZODB 3.3, it's intended that transaction managers be
- used instead of invoking methods directly on Transaction objects, and
- calling ``begin()`` on a transaction manager didn't have this old bug.
- However, ``Transaction.begin()`` still exists in 3.3, and it had a worse
- bug: it never aborted the transaction (not even if changes were pending
- outside of subtransactions). ``Transaction.begin()`` has been changed to
- abort the transaction, although it's still strongly recommended to invoke
- ``begin()`` on the relevant transaction manager instead. For example::
+- Growing pains: ZODB 3.2 had a bug wherein ``Transaction.begin()`` didn't
+ abort the current transaction if the only pending changes were in a
+ subtransaction. In ZODB 3.3, it's intended that a transaction manager be
+ used to effect ``begin()`` (instead of invoking ``Transaction.begin()``),
+ and calling ``begin()`` on a transaction manager didn't have this old
+ bug. However, ``Transaction.begin()`` still exists in 3.3, and it had a
+ worse bug: it never aborted the transaction (not even if changes were
+ pending outside of subtransactions). ``Transaction.begin()`` has been
+ changed to abort the transaction. ``Transaction.begin()`` is also
+ deprecated. Don't use it. Use ``begin()`` on the relevant transaction
+ manager instead. For example,
- import transaction
- transaction.begin()
+ >>> import transaction
+ >>> txn = transaction.begin() # start a txn using the default TM
if using the default ThreadTransactionManager (see news for 3.3a3 below).
+ In 3.3, it's intended that a single Transaction object is used for exactly
+ one transaction. So, unlike as in 3.2, when somtimes Transaction objects
+ were reused across transactions, but sometimes weren't, when you do
+ ``Transaction.begin()`` in 3.3 a brand new transaction object is
+ created. That's why this use is deprecated. Code of the form:
+ >>> txn = transaction.get()
+ >>> ...
+ >>> txn.begin()
+ >>> ...
+ >>> txn.commit()
+
+ can't work as intended is 3.3, because ``txn`` is no longer the current
+ Transaction object the instant ``txn.begin()`` returns.
+
+
+
BTrees
------
Modified: ZODB/branches/3.3/src/ZODB/tests/testZODB.py
===================================================================
--- ZODB/branches/3.3/src/ZODB/tests/testZODB.py 2004-09-10 01:46:02 UTC (rev 27487)
+++ ZODB/branches/3.3/src/ZODB/tests/testZODB.py 2004-09-10 03:25:47 UTC (rev 27488)
@@ -386,39 +386,58 @@
# transaction, and, in fact, when this test was written,
# Transaction.begin() didn't do anything (everything from here
# down failed).
- cn = self._db.open()
- rt = cn.root()
- rt['a'] = 1
- transaction.get().begin() # should abort adding 'a' to the root
- rt = cn.root()
- self.assertRaises(KeyError, rt.__getitem__, 'a')
+ # Oh, bleech. Since Transaction.begin is also deprecated, we have
+ # to goof around suppressing the deprecation warning.
+ import warnings
- # A longstanding bug: this didn't work if changes were only in
- # subtransactions.
- transaction.get().begin()
- rt = cn.root()
- rt['a'] = 2
- transaction.get().commit(1)
+ # First verify that Transaction.begin *is* deprecated, by turning
+ # the warning into an error.
+ warnings.filterwarnings("error", category=DeprecationWarning)
+ self.assertRaises(DeprecationWarning, transaction.get().begin)
+ del warnings.filters[0]
- transaction.get().begin()
- rt = cn.root()
- self.assertRaises(KeyError, rt.__getitem__, 'a')
+ # Now ignore DeprecationWarnings for the duration. Use a
+ # try/finally block to ensure we reenable DeprecationWarnings
+ # no matter what.
+ warnings.filterwarnings("ignore", category=DeprecationWarning)
+ try:
+ cn = self._db.open()
+ rt = cn.root()
+ rt['a'] = 1
- # One more time, mixing "top level" and subtransaction changes.
- transaction.get().begin()
- rt = cn.root()
- rt['a'] = 3
- transaction.get().commit(1)
- rt['b'] = 4
+ transaction.get().begin() # should abort adding 'a' to the root
+ rt = cn.root()
+ self.assertRaises(KeyError, rt.__getitem__, 'a')
- transaction.get().begin()
- rt = cn.root()
- self.assertRaises(KeyError, rt.__getitem__, 'a')
- self.assertRaises(KeyError, rt.__getitem__, 'b')
+ # A longstanding bug: this didn't work if changes were only in
+ # subtransactions.
+ transaction.get().begin()
+ rt = cn.root()
+ rt['a'] = 2
+ transaction.get().commit(1)
- cn.close()
+ transaction.get().begin()
+ rt = cn.root()
+ self.assertRaises(KeyError, rt.__getitem__, 'a')
+ # One more time, mixing "top level" and subtransaction changes.
+ transaction.get().begin()
+ rt = cn.root()
+ rt['a'] = 3
+ transaction.get().commit(1)
+ rt['b'] = 4
+
+ transaction.get().begin()
+ rt = cn.root()
+ self.assertRaises(KeyError, rt.__getitem__, 'a')
+ self.assertRaises(KeyError, rt.__getitem__, 'b')
+
+ cn.close()
+
+ finally:
+ del warnings.filters[0]
+
def test_suite():
return unittest.makeSuite(ZODBTests, 'check')
Modified: ZODB/branches/3.3/src/transaction/_transaction.py
===================================================================
--- ZODB/branches/3.3/src/transaction/_transaction.py 2004-09-10 01:46:02 UTC (rev 27487)
+++ ZODB/branches/3.3/src/transaction/_transaction.py 2004-09-10 03:25:47 UTC (rev 27488)
@@ -136,6 +136,7 @@
import logging
import sys
import thread
+import warnings
_marker = object()
@@ -230,6 +231,9 @@
self._resources.append(adapter)
def begin(self):
+ warnings.warn("Transaction.begin() should no longer be used; use "
+ "the begin() method of a transaction manager.",
+ DeprecationWarning)
if (self._resources or
self._sub or
self._nonsub or
More information about the Zodb-checkins
mailing list