[ZODB-Dev] Problem with Bsddb3Storage.copyTransactionsFrom
Barry A. Warsaw
barry@zope.com
Fri, 2 Nov 2001 14:18:00 -0500
>>>>> "JH" =3D=3D Jeremy Hylton <jeremy@zope.com> writes:
JH> I think we should support None. Take a look at line 157 of
JH> ZODB/DB.py. It's the transaction that creates the root object
JH> in an empty storage. It uses None.
Duh. I need to get my eyes examined; Full supports this of course!
Here's the test case I added to verify this:
-------------------- snip snip --------------------BasicStorage.py
def checkSerialIsNoneForInitialRevision(self):
eq =3D self.assertEqual
oid =3D self._storage.new_oid()
txn =3D self._transaction
self._storage.tpc_begin(txn)
# Use None for serial. Don't use _dostore() here because that =
coerces
# serial=3DNone to serial=3DZERO.
newrevid =3D self._storage.store(oid, None, zodb_pickle(MinPO(1=
1)),
'', txn)
self._storage.tpc_vote(txn)
self._storage.tpc_finish(txn)
data, revid =3D self._storage.load(oid, '')
value =3D zodb_unpickle(data)
eq(value, MinPO(11))
eq(revid, newrevid)
-------------------- snip snip --------------------
Full passes this test, but ZEO with FileStorage does not:
-------------------- snip snip --------------------
FAIL: checkSerialIsNoneForInitialRevision (ZEO.tests.testZEO.ZEOFileSto=
rageTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "lib.linux-i686-2.1/ZODB/tests/BasicStorage.py", line 83, in che=
ckSerialIsNoneForInitialRevision
eq(revid, newrevid)
File "/usr/local/lib/python2.1/unittest.py", line 273, in failUnlessE=
qual
raise self.failureException, (msg or '%s !=3D %s' % (first, second)=
)
AssertionError: =03@h[o=D1G; !=3D None
-------------------- snip snip --------------------
I'm getting a bunch of other failures in ZEOFileStorageTest and
testBTrees with current CVS, too though.
I wasn't very clear in my previous message:
>>>>> "BAW" =3D=3D Barry A Warsaw <barry@zope.com> writes:
BAW> For some reason, your script is passing a None to the serial
BAW> argument to store() and you're getting a conflict that
BAW> tryToResolveConflict() is unable to resolve. Full then wants
BAW> to raise a ConflictError, but it tries unconditionally to
BAW> stringify the serial via utils.U64(). That doesn't work when
BAW> passing in None.
BAW> This doesn't explain why None is getting passed in though.
What is /really/ happening is that for some reason your storage
already has a revision for the object, so its old serial number exists
-- i.e. the object is /not/ being created, but None is still being
passed in for the serial argument. /That/ is what doesn't make sense!
Passing serial=3DNone for object creation is no problem. But you will
get a conflict error if serial=3DNone when the object already has
revisions in the storage. That seems as it should be.
-Barry