-
Barry Warsaw authored
(finally) been defined: the serial number of objects in the non-version after an abortVersion should be the last serial number of the object before it was modified in the version. This actually breaks the symmetry between serial numbers and transaction ids, so it must be handled specially. Specific changes include: _setupDBs(): Updated documentation. _finish(): Recognize the 'a' opcode, which is subtly different than the 'o' opcode. When the 'a' opcode is seen, we'll store both the "live revision id" and the current transaction id in the _serials table. The former id is the serial number of the last change to the non-version data. If we're seeing the 'o' or 'x' opcodes, we'll save None as the serial number, which tells the loop at the end of the function that the object serial number and the transaction id are the same (overwhelmingly, the most common case). When serial# <> tid, we'll concatenate the two values together into serial+tid as the value of the _serials's oid key. So the value can now be an 8-byte string (the common case), or a 16-byte string when serial# <> tid. _getSerialAndTid(): A new function which returns a 2-tuple of the oid's current serial number and the tid of the last transaction that modified the object. Usually these are the same, but in the face of abortVersion, they're not. _getSerialAndTidMissingOk(): Like _getSerialAndTid() but if the oid isn't in the _serials table, return (None, None) instead of raising a KeyError. Sometimes we need different table access semantics. abortVersion(), commitVersion(), modifiedInVersion(), load(), getSerial(), transactionalUndo(), history(), _dopack(): Use the new _getSerialAndTid() access method to get the serial# and tid for the last object modification, instead of accessing the _serials table directly. store(), _rootreachable(): Use _getSerialAndTidMissingOk()
9933d242