[Zope3-checkins] CVS: Zope/lib/python/ZODB/tests -
testPersistentMapping.py:1.8 test_datamanageradapter.py:1.4
Tim Peters
tim.one at comcast.net
Mon Apr 5 14:48:25 EDT 2004
Update of /cvs-repository/Zope/lib/python/ZODB/tests
In directory cvs.zope.org:/tmp/cvs-serv30273/lib/python/ZODB/tests
Modified Files:
testPersistentMapping.py test_datamanageradapter.py
Log Message:
Removed Transaction.py. The new transaction package takes its place.
get_transaction() is still stuffed into __builtin__ as a magical side
effect of importing ZODB.
=== Zope/lib/python/ZODB/tests/testPersistentMapping.py 1.7 => 1.8 ===
--- Zope/lib/python/ZODB/tests/testPersistentMapping.py:1.7 Fri Nov 28 11:44:54 2003
+++ Zope/lib/python/ZODB/tests/testPersistentMapping.py Mon Apr 5 14:48:22 2004
@@ -24,7 +24,7 @@
import ZODB
from ZODB.MappingStorage import MappingStorage
-from ZODB.Transaction import Transaction
+from transaction import Transaction
import cPickle
import cStringIO
import sys
=== Zope/lib/python/ZODB/tests/test_datamanageradapter.py 1.3 => 1.4 ===
--- Zope/lib/python/ZODB/tests/test_datamanageradapter.py:1.3 Thu Mar 11 10:57:57 2004
+++ Zope/lib/python/ZODB/tests/test_datamanageradapter.py Mon Apr 5 14:48:22 2004
@@ -17,7 +17,7 @@
"""
import unittest
from doctest import DocTestSuite
-from ZODB.Transaction import DataManagerAdapter
+from transaction._transaction import DataManagerAdapter
from ZODB.tests.sampledm import DataManager
def test_normal_commit():
@@ -34,7 +34,7 @@
Now we'll commit the changes. When the data manager joins a transaction,
the transaction will create an adapter.
-
+
>>> dma = DataManagerAdapter(dm)
and register it as a modified object. At commit time, the
@@ -54,7 +54,7 @@
Then the transaction will call commit on the jar:
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
This doesn't actually do anything. :)
@@ -77,7 +77,7 @@
>>> jar.tpc_finish(t1)
and the data manager finishes the two-phase commit:
-
+
>>> dm.state, dm.delta
(1, 0)
>>> dm.prepared
@@ -98,7 +98,7 @@
When the data manager joins a transaction,
the transaction will create an adapter.
-
+
>>> dma = DataManagerAdapter(dm)
and register it as a modified object.
@@ -116,7 +116,7 @@
Then the transaction will call abort on the jar:
>>> t1 = '1'
- >>> jar.abort(dma, t1)
+ >>> jar.abort(t1)
Which aborts the changes in the data manager:
@@ -138,7 +138,7 @@
Now we'll commit the changes. When the data manager joins a transaction,
the transaction will create an adapter.
-
+
>>> dma = DataManagerAdapter(dm)
and register it as a modified object. At commit time, the
@@ -158,7 +158,7 @@
Then the transaction will call commit on the jar:
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
This doesn't actually do anything. :)
@@ -189,7 +189,7 @@
Now we'll commit the changes. When the data manager joins a transaction,
the transaction will create an adapter.
-
+
>>> dma = DataManagerAdapter(dm)
and register it as a modified object. At commit time, the
@@ -209,7 +209,7 @@
Then the transaction will call commit on the jar:
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
This doesn't actually do anything. :)
@@ -254,7 +254,7 @@
Now we'll commit the changes in a subtransaction. When the data
manager joins a transaction, the transaction will create an
adapter.
-
+
>>> dma = DataManagerAdapter(dm)
and register it as a modified object. At commit time, the
@@ -274,7 +274,7 @@
Then the transaction will call commit on the jar:
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
This doesn't actually do anything. :)
@@ -304,7 +304,7 @@
>>> dm.state, dm.delta
(0, 2)
>>> jar.tpc_begin(t1, 1) # 1 -> subtxn
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
>>> jar.tpc_vote(t1)
>>> jar.tpc_finish(t1)
>>> dm.state, dm.delta
@@ -313,7 +313,7 @@
>>> dm.state, dm.delta
(0, 3)
>>> jar.tpc_begin(t1, 1) # 1 -> subtxn
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
>>> jar.tpc_vote(t1)
>>> jar.tpc_finish(t1)
>>> dm.state, dm.delta
@@ -328,13 +328,13 @@
>>> dm.inc()
>>> dm.state, dm.delta
(0, 5)
-
+
and then commit the top-level transaction.
The transaction will actually go through the steps for a subtransaction:
>>> jar.tpc_begin(t1, 1) # 1 -> subtxn
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
>>> jar.tpc_vote(t1)
>>> jar.tpc_finish(t1)
@@ -350,7 +350,7 @@
The transaction manager doesn's call tpc_begin, because commit_sub
implies the start of two-phase commit. Next, it does call commit:
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
which doesn't do anything.
@@ -370,7 +370,7 @@
>>> jar.tpc_finish(t1)
and the data manager finishes the two-phase commit:
-
+
>>> dm.state, dm.delta
(5, 0)
>>> dm.prepared
@@ -392,7 +392,7 @@
Now we'll commit the changes in a subtransaction. When the data
manager joins a transaction, the transaction will create an
adapter.
-
+
>>> dma = DataManagerAdapter(dm)
and register it as a modified object. At commit time, the
@@ -412,7 +412,7 @@
Then the transaction will call commit on the jar:
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
This doesn't actually do anything. :)
@@ -442,13 +442,13 @@
>>> dm.state, dm.delta
(0, 2)
>>> jar.tpc_begin(t1, 1) # 1 -> subtxn
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
>>> jar.tpc_vote(t1)
>>> jar.tpc_finish(t1)
>>> dm.state, dm.delta
(0, 2)
-
+
>>> dm.inc()
>>> dm.state, dm.delta
(0, 3)
@@ -457,19 +457,19 @@
The transaction will just call abort as usual:
- >>> jar.abort(dma, t1)
+ >>> jar.abort(t1)
This will cause a rollback to the last savepoint:
>>> dm.state, dm.delta
(0, 2)
Then we do more work:
-
+
>>> dm.inc()
>>> dm.state, dm.delta
(0, 3)
>>> jar.tpc_begin(t1, 1) # 1 -> subtxn
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
>>> jar.tpc_vote(t1)
>>> jar.tpc_finish(t1)
>>> dm.state, dm.delta
@@ -484,13 +484,13 @@
>>> dm.inc()
>>> dm.state, dm.delta
(0, 5)
-
+
and then commit the top-level transaction.
The transaction will actually go through the steps for a subtransaction:
>>> jar.tpc_begin(t1, 1) # 1 -> subtxn
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
>>> jar.tpc_vote(t1)
>>> jar.tpc_finish(t1)
@@ -506,7 +506,7 @@
The transaction manager doesn's call tpc_begin, because commit_sub
implies the start of two-phase commit. Next, it does call commit:
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
which doesn't do anything.
@@ -526,7 +526,7 @@
>>> jar.tpc_finish(t1)
and the data manager finishes the two-phase commit:
-
+
>>> dm.state, dm.delta
(5, 0)
>>> dm.prepared
@@ -548,7 +548,7 @@
Now we'll commit the changes in a subtransaction. When the data
manager joins a transaction, the transaction will create an
adapter.
-
+
>>> dma = DataManagerAdapter(dm)
and register it as a modified object. At commit time, the
@@ -568,7 +568,7 @@
Then the transaction will call commit on the jar:
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
This doesn't actually do anything. :)
@@ -598,7 +598,7 @@
>>> dm.state, dm.delta
(0, 2)
>>> jar.tpc_begin(t1, 1) # 1 -> subtxn
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
>>> jar.tpc_vote(t1)
>>> jar.tpc_finish(t1)
>>> dm.state, dm.delta
@@ -607,7 +607,7 @@
>>> dm.state, dm.delta
(0, 3)
>>> jar.tpc_begin(t1, 1) # 1 -> subtxn
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
>>> jar.tpc_vote(t1)
>>> jar.tpc_finish(t1)
>>> dm.state, dm.delta
@@ -622,18 +622,18 @@
>>> dm.inc()
>>> dm.state, dm.delta
(0, 5)
-
+
and then abort the top-level transaction.
The transaction first call abort on the jar:
- >>> jar.abort(dma, t1)
+ >>> jar.abort(t1)
This will have the effect of aborting the subtrancation:
>>> dm.state, dm.delta
(0, 3)
-
+
Then the transaction will call abort_sub:
>>> jar.abort_sub(t1)
@@ -660,7 +660,7 @@
Now we'll commit the changes in a subtransaction. When the data
manager joins a transaction, the transaction will create an
adapter.
-
+
>>> dma = DataManagerAdapter(dm)
and register it as a modified object. At commit time, the
@@ -680,7 +680,7 @@
Then the transaction will call commit on the jar:
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
This doesn't actually do anything. :)
@@ -710,13 +710,13 @@
>>> dm.state, dm.delta
(0, 2)
>>> jar.tpc_begin(t1, 1) # 1 -> subtxn
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
>>> jar.tpc_vote(t1)
>>> jar.tpc_finish(t1)
>>> dm.state, dm.delta
(0, 2)
-
+
>>> dm.inc()
>>> dm.state, dm.delta
(0, 3)
@@ -725,19 +725,19 @@
The transaction will just call abort as usual:
- >>> jar.abort(dma, t1)
+ >>> jar.abort(t1)
This will cause a rollback to the last savepoint:
>>> dm.state, dm.delta
(0, 2)
Then we do more work:
-
+
>>> dm.inc()
>>> dm.state, dm.delta
(0, 3)
>>> jar.tpc_begin(t1, 1) # 1 -> subtxn
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
>>> jar.tpc_vote(t1)
>>> jar.tpc_finish(t1)
>>> dm.state, dm.delta
@@ -752,13 +752,13 @@
>>> dm.inc()
>>> dm.state, dm.delta
(0, 5)
-
+
and then commit the top-level transaction.
The transaction will actually go through the steps for a subtransaction:
>>> jar.tpc_begin(t1, 1) # 1 -> subtxn
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
>>> jar.tpc_vote(t1)
>>> jar.tpc_finish(t1)
@@ -774,7 +774,7 @@
The transaction manager doesn's call tpc_begin, because commit_sub
implies the start of two-phase commit. Next, it does call commit:
- >>> jar.commit(dma, t1)
+ >>> jar.commit(t1)
which doesn't do anything.
@@ -795,7 +795,7 @@
>>> jar.tpc_abort(t1)
An the changes are undone:
-
+
>>> dm.state, dm.delta
(0, 0)
>>> dm.prepared
More information about the Zope3-Checkins
mailing list