- 08 Apr, 2017 1 commit
-
-
Jim Fulton authored
This backports the following commits: 6d673057 244bb92b
-
- 03 Apr, 2017 1 commit
-
-
Kirill Smelkov authored
... instead of silently creating empty database on such opens. Use-case for this are utilities like e.g. zodbdump and zodbcmp which expect such storage opens to fail so that the tool can know there is no such storage and report it to user. In contrast current state is: read-only opens get created-on-the-fly empty storage with no content, but which can be iterated over without getting any error. This way e.g. `zodbdump non-existent.fs` produces empty output _and_ exit code 0 which is not what caller expects. (cherry picked from commit 30bbabf1)
-
- 06 Feb, 2017 1 commit
-
-
Julien Muchembled authored
-
- 02 Feb, 2017 5 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
This backports a change from commit 227953b9. NEO, as well as ZEO+server_sync (ERP5 backports this feature with a monkey-patch), pings the server (primary master node in the case of NEO) on new transactions. However, this round-trip is actually performed by the thread that also does tasks requiring to lock the DB, like processing of invalidations. Since transaction 1.6.1 (more precisely commit e581a120a6), IStorage.sync() is called indirectly by DB.open() when a transaction has already begun, and the DB must not be locked when this happens.
-
Jason Madden authored
Doing so leads to race conditions. In particular, there can be an AttributeError. See https://github.com/zodb/zodbshootout/issues/26 for details. (cherry picked from commit f8cf23ec)
-
Jason Madden authored
Don't require persistent at setup time. We don't build native code that needs those headers anymore. Fixes #119. (cherry picked from commit d7dae8b1)
-
Jim Fulton authored
This is also a workaround for pypa/setuptools#864, since the default pypy3 on Travis is quite old. (cherry picked from commit def73970 and 5dcca55e)
-
- 27 Nov, 2016 2 commits
-
-
Jim Fulton authored
-
Jim Fulton authored
Fixed to work with transaction 2.0.3.
-
- 25 Nov, 2016 1 commit
-
-
Jim Fulton authored
-
- 27 Sep, 2016 2 commits
-
-
Jim Fulton authored
Simplify the README file to avoid out of date information
-
Jim Fulton authored
We have the same information scattered around in different places, which increases the chance that some of it will be out of date. See the end of: https://groups.google.com/forum/#!topic/zodb/fy6RRVAF9-s I want to try to avoid duplicating zodb.org.
-
- 12 Sep, 2016 2 commits
-
-
Jim Fulton authored
Clear Connection.transaction_manager on close. Fixes #114 for ZODB 4.
-
Jason Madden authored
-
- 09 Sep, 2016 1 commit
-
-
Jim Fulton authored
Call _p_resolveConflict() even if a conflicting change doesn't change the state
-
- 21 Aug, 2016 2 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
This reverts to the behaviour of 3.10.3 and older.
-
- 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 4 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
-