Commit 306edcf3 authored by Tim Peters's avatar Tim Peters

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.
parent f9900afe
This diff is collapsed.
......@@ -15,11 +15,16 @@
__version__ = "3.3a2"
import sys
import __builtin__
from persistent import TimeStamp
from DB import DB
import Transaction
from transaction import get as get_transaction
# Backward compat for old imports. I don't think TimeStamp should
# really be in persistent anyway
# really be in persistent anyway.
sys.modules['ZODB.TimeStamp'] = sys.modules['persistent.TimeStamp']
# XXX Issue deprecation warning if this variant is used?
__builtin__.get_transaction = get_transaction
del __builtin__
......@@ -24,7 +24,7 @@ import unittest
import ZODB
from ZODB.MappingStorage import MappingStorage
from ZODB.Transaction import Transaction
from transaction import Transaction
import cPickle
import cStringIO
import sys
......
......@@ -13,11 +13,11 @@
##############################################################################
"""XXX short summary goes here.
$Id: test_datamanageradapter.py,v 1.3 2004/03/11 15:57:57 jeremy Exp $
$Id: test_datamanageradapter.py,v 1.4 2004/04/05 18:48:22 tim_one Exp $
"""
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():
......@@ -54,7 +54,7 @@ def test_normal_commit():
Then the transaction will call commit on the jar:
>>> jar.commit(dma, t1)
>>> jar.commit(t1)
This doesn't actually do anything. :)
......@@ -116,7 +116,7 @@ def test_abort():
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:
......@@ -158,7 +158,7 @@ def test_tpc_abort_phase1():
Then the transaction will call commit on the jar:
>>> jar.commit(dma, t1)
>>> jar.commit(t1)
This doesn't actually do anything. :)
......@@ -209,7 +209,7 @@ def test_tpc_abort_phase2():
Then the transaction will call commit on the jar:
>>> jar.commit(dma, t1)
>>> jar.commit(t1)
This doesn't actually do anything. :)
......@@ -274,7 +274,7 @@ def test_commit_w_subtransactions():
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 @@ def test_commit_w_subtransactions():
>>> 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 @@ def test_commit_w_subtransactions():
>>> 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
......@@ -334,7 +334,7 @@ def test_commit_w_subtransactions():
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 @@ def test_commit_w_subtransactions():
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.
......@@ -412,7 +412,7 @@ def test_commit_w_subtransactions_featuring_subtransaction_abort():
Then the transaction will call commit on the jar:
>>> jar.commit(dma, t1)
>>> jar.commit(t1)
This doesn't actually do anything. :)
......@@ -442,7 +442,7 @@ def test_commit_w_subtransactions_featuring_subtransaction_abort():
>>> 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
......@@ -457,7 +457,7 @@ def test_commit_w_subtransactions_featuring_subtransaction_abort():
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
......@@ -469,7 +469,7 @@ def test_commit_w_subtransactions_featuring_subtransaction_abort():
>>> 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
......@@ -490,7 +490,7 @@ def test_commit_w_subtransactions_featuring_subtransaction_abort():
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 @@ def test_commit_w_subtransactions_featuring_subtransaction_abort():
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.
......@@ -568,7 +568,7 @@ def test_abort_w_subtransactions():
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 @@ def test_abort_w_subtransactions():
>>> 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 @@ def test_abort_w_subtransactions():
>>> 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
......@@ -627,7 +627,7 @@ def test_abort_w_subtransactions():
The transaction first call abort on the jar:
>>> jar.abort(dma, t1)
>>> jar.abort(t1)
This will have the effect of aborting the subtrancation:
......@@ -680,7 +680,7 @@ def test_tpc_abort_w_subtransactions_featuring_subtransaction_abort():
Then the transaction will call commit on the jar:
>>> jar.commit(dma, t1)
>>> jar.commit(t1)
This doesn't actually do anything. :)
......@@ -710,7 +710,7 @@ def test_tpc_abort_w_subtransactions_featuring_subtransaction_abort():
>>> 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
......@@ -725,7 +725,7 @@ def test_tpc_abort_w_subtransactions_featuring_subtransaction_abort():
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
......@@ -737,7 +737,7 @@ def test_tpc_abort_w_subtransactions_featuring_subtransaction_abort():
>>> 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
......@@ -758,7 +758,7 @@ def test_tpc_abort_w_subtransactions_featuring_subtransaction_abort():
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 @@ def test_tpc_abort_w_subtransactions_featuring_subtransaction_abort():
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.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment