- 15 Jun, 2016 3 commits
-
-
Jim Fulton authored
It wasn't really needed or used and caused a stupid ZEO test failure. I do think the storage API needs to be thought about and refined at some point, but now, it's not a priority.
-
Jim Fulton authored
I'd lazily assumed that undo and tpc_vote has the same sorts of returns, but they don't. When tpc_vote isn't None (ZEO), the retrun is a list of oid and serial pairs.
-
Jim Fulton authored
To prevent modifying the set of instances while iterating over them.
-
- 14 Jun, 2016 1 commit
-
-
Jim Fulton authored
That's applied to storages other than RelStorage. See: https://groups.google.com/forum/#!topic/zodb/QJYmvF0eUUM
-
- 11 Jun, 2016 4 commits
-
-
Jim Fulton authored
-
Jim Fulton authored
-
Jim Fulton authored
-
Jim Fulton authored
And in special case where a connectin is opened while a transaction is active (Zope2).
-
- 10 Jun, 2016 2 commits
-
-
Jim Fulton authored
It's too hard to remember to update the meta data (we've been in beta for a long long time).
-
Jim Fulton authored
-
- 09 Jun, 2016 2 commits
-
-
Jim Fulton authored
-
Jim Fulton authored
By resetting self.__onCloseCallbacks before calling the close callbacks to forestall infinite recursion (as can be the case when a close callback is the database close methos).
-
- 07 Jun, 2016 3 commits
-
-
Jim Fulton authored
Changed it to the value corresponding to the maximim *signed* big-endian 64-bit integer, because of LxBTrees. Note that this value isn't used anywhere in ZODB yet. Maybe it should be.
-
Jim Fulton authored
-
Jim Fulton authored
To mitigate errors during tearDown. Lots of tests are sloppy about closing connection (because they could be), but storages tend to get closed and transactions aborted. This has the effedt of calling afterCompletion on connections which tries to call storage lastTransaction, which causes errors.
-
- 06 Jun, 2016 3 commits
-
-
Jim Fulton authored
-
Jim Fulton authored
Fixed: FileStorage loadBefore didn't handle deleted/undone data correctly
-
Jim Fulton authored
Enforce minimum required Python versions: 2.7, 3.3. +1
-
- 05 Jun, 2016 1 commit
-
-
Jim Fulton authored
-
- 31 May, 2016 1 commit
-
-
Jim Fulton authored
Merge pull request #62 from zopefoundation/dont-depend-on-implementation-detail-in-tpc_finish-test-assertions Fixed a test that depended on some off behavior of tpc_finish in some…
-
- 30 May, 2016 1 commit
-
-
Jim Fulton authored
-
- 17 May, 2016 2 commits
-
-
Jim Fulton authored
This and https://github.com/zodb/relstorage/pull/31 make RelStorage pass with this branch (as much as they pass with master).
-
Tres Seaver authored
Closes #59.
-
- 12 May, 2016 1 commit
-
-
Julien Muchembled authored
This answers #13
-
- 09 May, 2016 3 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
- It failed with oids that already exist in the base storage. - MappingStorage returned timestamps in wrong format.
-
Julien Muchembled authored
-
- 05 May, 2016 5 commits
-
-
Jim Fulton authored
-
Jim Fulton authored
-
Jim Fulton authored
-
Jim Fulton authored
On Python 2 and Mac OS X, checkFlushAfterTruncate was failing.
-
Jim Fulton authored
-
- 04 May, 2016 7 commits
-
-
Jim Fulton authored
Even though the previous commit otherwise made MVCCMappingStorage and IMVCCStorage handling better.
-
Jim Fulton authored
The previous commit, made in anger, made a test pass, but wasn't really the right fix. This commit fixes MVCCMappingStorage's loadBefore implementation by fixing handling of the internal _ltid variable so that it's updated during poll_invalidations. This allowed the base class version of loadBefore to be used and, I'm 97% sure has the right semantics. Fixing this revealed a problem with the Connection changes. Fixed Connection.py to poll for invalidations before computing _txn_time by calling lastTransaction, so as to get a current value. We still apply invalidations after computing _txn_time, so that persistent classes can be loaded correctly when they are invalidated. This was accomplished by weaving _flush_invalidations into newTransaction.
-
Jim Fulton authored
Changed to always empty the file pool. I doubt that just flushing on Python 2 was much of an optimization, and ... Python 2. :)
-
Jim Fulton authored
This is needed because pack temporarily deletes data from the data structure that loadBefore reads. Note that in the new scheme of things, we avoid using load, but instead use loadBefore. This we bypass the _data_snapshot shenanigans, which makes me think we aren't testing what we should be, but I have no confidence that the machinery in MVCCMappingStorage actually reflects anything meaningful.
-
Jim Fulton authored
-
Jim Fulton authored
-
Jim Fulton authored
This implements: https://github.com/zopefoundation/ZODB/issues/50 Rather than watching invalidations, simply use 1 + the storages lastTransaction, which is equivalent to but much simpler than waiting for the first invalidation after a transaction starts. More importantly, it means we can always use loadBefore and get away from load. We no longer have to worry about ordering of invalidations and load() results. Much thanks to NEO for pointing the way toward this simplification! Implementing this initially caused a deadlock, because DB.open() called Connection.open() while holding a database lock and Connection.open() now calls IStotage.lastTransaction(), which acquires a storage lock. (It's not clear that lastTransaction() really needs a storage lock.) Meanwhile, IStotage.tpc_finish() calls a DB function that requires the DB lock while holding the storage lock. Fixing this required moving the call to Connection.open() outside the region where the DB lock was held. To debug the problem above, I greatly improved lock-debugging support. Now all of the ZODB code imports Lock, RLock and Condition from ZODB.utils. If the DEBUG_LOCKING is set to a non-empty value, then these are wrapped in such a way that debugging information is printed as they are used. This made spotting the nature of the deadlock easier. Of course, a change this basic broke lots of tests. Most of the breakage arises from the fact that connections now call lastTransaction on storages at transaction boundaries. Lots of tests didn't clean up databases and connections properly. I fixed many tests, but ultimately gave up and added some extra cleanup code that violated transaction-manager underware (and the underware's privates) to clear transaction synchonizers in test setup and tear-down. I plan to add a transaction manager API for this and to use it in a subsequent PR. This tests makes database and connection hygiene a bit more important, especially for tests, because a connection will continue to interact with storages if it isn't properly closed, which can lead to errors if the storage is closed. I chose not to swallow these errors in Connection, choosing rather to clean up tests. The thread debugging and test changes make this PR larger than I would have liked. Apologies in advance to the reviewers.
-
- 29 Apr, 2016 1 commit
-
-
Tres Seaver authored
Incididentally, should make the Py26 winbot happy too, until we can get it disabled.
-