- 04 Aug, 2016 1 commit
-
-
Jim Fulton authored
-
- 27 Jul, 2016 2 commits
-
-
Jim Fulton authored
checkTransactionalUndoIterator: do not expect iterator to return sorted oids
-
Julien Muchembled authored
-
- 26 Jul, 2016 1 commit
-
-
Jim Fulton authored
fstail: print the txn offset and header size, instead of only the data offset
-
- 13 Jul, 2016 1 commit
-
-
Julien Muchembled authored
-
- 12 Jul, 2016 8 commits
-
-
Julien Muchembled authored
Before: 2016-07-01 09:41:50.416574: hash=d7101c5ee7b8e412d7b6d54873204421e09b7f34 user='' description='' length=1629 offset=58990284 After: 2016-07-01 09:41:50.416574: hash=d7101c5ee7b8e412d7b6d54873204421e09b7f34 user='' description='' length=1629 offset=58990261 (+23) The structure of a FileStorage DB is such that it's easy to revert the last transactions, by truncating the file at the right offset. With the above change, `fstail` can now be used to get this offset. In the above example: truncate -s 58990261 Data.fs would delete the transaction and all those after.
-
Jim Fulton authored
Refactored FileStorage transactional undo
-
Jim Fulton authored
-
Jim Fulton authored
Fix handle_all_serials for the new and old protocols.
-
Jason Madden authored
-
Jim Fulton authored
-
Jim Fulton authored
As part of a project to provide object-level commit locks for ZEO, I'm refactiring FileStorage to maintain transaction-specific data in Tranaction.data. This involved undo. In trying to figure this out, I found: - A bug in _undoDataInfo, which I verified with some tests and - _transactionalUndoRecord was maddeningly difficult to reason about (and thus change). I was concerned less by the bug than my inability to know whether a change to the code would be correct. So I refactored the code, mainly transactionalUndoRecord, to make the code easier to understand, fixing some logic errors (I'm pretty sure) along the way. This included lots of comments. (Comments are much easier to compose when you're working out logic you didn't understand.) In addition to makeing the code cleaner, it allows undo to be handled in cases that weren't handled before.
-
Jim Fulton authored
-
- 09 Jul, 2016 1 commit
-
-
Jason Madden authored
-
- 08 Jul, 2016 1 commit
-
-
Jim Fulton authored
-
- 05 Jul, 2016 3 commits
-
-
Jim Fulton authored
Only tpc_vote can report resolved conflicts with the new commit protocol
-
Julien Muchembled authored
-
Julien Muchembled authored
-
- 04 Jul, 2016 8 commits
-
-
Jim Fulton authored
-
Jim Fulton authored
Better support of the new API to notify of resolved conflicts (store/tpc_finish)
-
Jim Fulton authored
Conflicts: src/ZODB/interfaces.py
-
Julien Muchembled authored
-
Jim Fulton authored
-
Jim Fulton authored
-
Jim Fulton authored
ZEO handles undo asynchronously and ZODB has for some time allowed undo oids to be returned via vote.
-
Jim Fulton authored
-
- 01 Jul, 2016 5 commits
-
-
Jim Fulton authored
-
Jim Fulton authored
Define a new interface for storages that support the new commit protocol.
-
Jim Fulton authored
-
Jim Fulton authored
-
Julien Muchembled authored
When switching all storages to the new API in the master branch, I found a few issues, mainly with blobs. 1. Created/modified blobs are invalidated during the first phase (in Connection._store_objects): obj._p_invalidate() And with the old API, _handle_serial then sets _p_serial Ghost objects are not supposed to have a _p_serial and with the new API, a few tests would fail because _p_serial are checked without activating the blob first. 2. Another consequence of _handle_serial not updating _p_changed/_p_serial immediately is that created objects are stored twice if __getstate__ modifies itself. This case is tested in testConnection by doctest_lp485456_setattr_in_setstate_doesnt_cause_multiple_stores Hence the change in Connection._commit: - self._modified is already appended in Connection._store_objects - (obj._p_serial == z64) instead of (oid in self._creating) would not work for savepoints. 3. Setting _p_changed of a Blob with no uncommitted changes would cause an error (lp440234_Setting__p_changed_of_a_Blob_w_no_uncomitted_changes_is_noop) Fixed by the same change as in 2: - oid was appended twice to self._modified but reverted one (self._modified.pop() in _store_objects) - the test passed because _p_changed was reset early by _handle_serial
-
- 30 Jun, 2016 4 commits
-
-
Jim Fulton authored
This allows interface incompatibilities: - Future version of ZODB that requires the new protocol being configured with a storage that doesn't implement the new protocol - ZEO has a client that uses the old protocol can't use a storage that implements the new protocol. To be caught early. This commit also clarifies that the serial returned by ``undo()`` is ignored.
-
Jim Fulton authored
This reverts commit 7901868a.
-
Jim Fulton authored
This allows interface incompatibilities: - Future version of ZODB that requires the new protocol being configured with a storage that doesn't implement the new protocol - ZEO has a client that uses the old protocol can't use a storage that implements the new protocol. To be caught early. This commit also clarifies that the serial returned by ``undo()`` is ignored.
-
Jim Fulton authored
-
- 21 Jun, 2016 1 commit
-
-
Jim Fulton authored
Allow serial to be returned as late as tpc_finish
-
- 19 Jun, 2016 3 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
-
Vincent Pelletier authored
This makes possible for storage to allocate serial inside tpc_finish, removing the requirement to serialise 2PC's second phase phase (tpc_vote to tpc_finish/tpc_abort). Co-Authored-By: Julien Muchembled <jm@nexedi.com>
-
- 18 Jun, 2016 1 commit
-
-
Julien Muchembled authored
-