- 16 Jun, 2016 1 commit
-
-
Jim Fulton authored
-
- 13 Jun, 2016 2 commits
-
-
Jim Fulton authored
Fix winbot failures Thanks
-
Jim Fulton authored
-
- 11 Jun, 2016 2 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
This fixes the following random failure: Failure in test checkBaseHistory (ZODB.tests.testDemoStorage.DemoStorageTests) Traceback (most recent call last): File "unittest\case.py", line 384, in _executeTestPart function() File "ZODB\tests\testDemoStorage.py", line 96, in checkBaseHistory self._checkHistory(base_only()) File "ZODB\tests\HistoryStorage.py", line 46, in _checkHistory self.assertLess(a, b) File "unittest\case.py", line 1026, in assertLess self.fail(self._formatMessage(msg, standardMsg)) File "unittest\case.py", line 508, in fail raise self.failureException(msg) AssertionError: 1465433823.260304 not less than 1465433823.260304
-
- 06 Jun, 2016 6 commits
-
-
Jim Fulton authored
-
Jim Fulton authored
-
Jim Fulton authored
Conflicts: CHANGES.rst Cuz I neglected to push when I made 4.3.0. Thanks DCVS!
-
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 3 commits
-
-
Jim Fulton authored
-
Jim Fulton authored
-
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 1 commit
-
-
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 3 commits
-
-
Jim Fulton authored
-
Jim Fulton authored
On Python 2 and Mac OS X, checkFlushAfterTruncate was failing.
-
Jim Fulton authored
-
- 04 May, 2016 1 commit
-
-
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. :)
-
- 29 Apr, 2016 2 commits
-
-
Tres Seaver authored
Incididentally, should make the Py26 winbot happy too, until we can get it disabled.
-
Tres Seaver authored
Fixed test failure introduced in pull-request 51
-
- 28 Apr, 2016 2 commits
-
-
Jim Fulton authored
Fix possible data corruption after FileStorage is truncated to roll back a transaction
-
https://github.com/zopefoundation/ZODB/pull/51Jim Fulton authored
The PR depended on system time being UTC.
-
- 27 Apr, 2016 4 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
Multi-threaded IO support, which is new to ZODB 3.10, allows clients to read data (load & loadBefore) even after tpc_vote has started to write a new transaction to disk. This is done by using different 'file' objects. Issues start when a transaction is rolled back after data has been appended (using the writing file object). Truncating is not enough because the FilePool may have been used concurrently to read the end of the last transaction: file objects have their own read buffers which, in this case, may also contain the beginning of the aborted transaction. So a solution is to invalidate read buffers whenever they may contain wrong data. This patch does it on truncation, which happens rarely enough to not affect performance. We discovered this bug in the following conditions: - ZODB splitted in several FileStorage - many conflicts in the first committed DB, but always resolved - unresolved conflict in another DB If the transaction is replayed with success (no more conflict in the other DB), a subsequent load of the object that could be resolved in the first DB may, for example, return a wrong serial (tid of the aborted transaction) if the layout of the committed transaction matches that of the aborted one. The bug usually manifests with POSKeyError & CorruptedDataError exceptions in ZEO logs, for example while trying to resolve a conflict (and restarting the transaction does not help, causing Site Errors in Zope). But theorically, this could also cause silent corruption or unpickling errors at client side.
-
Julien Muchembled authored
-
Julien Muchembled authored
Cleanup dependencies, remove ZEO leftovers
-
- 25 Apr, 2016 2 commits
-
-
Julien Muchembled authored
-
Julien Muchembled authored
- remove now useless `zdaemon` dependency - remove ZEO documentation - update dependency list in README
-
- 04 Apr, 2016 1 commit
-
-
Jason Madden authored
patch time.time in historical_connections to avoid windows failures; fix race condition in pool.availableGC * patch time.time in historical_connections to avoid windows failures. * Also use a mock version of datetime.datetime.utcnow. We can't patch the method in-place because it's an extension type. * synchronize sleep with time * increment by less than the pool timeout to avoid a race condition. * Avoid mutating the dict as we iter over it. Seen in Python 3.4 tests: File "/home/travis/build/zopefoundation/ZODB/src/ZODB/historical_connections.txt", line 263, in historical_connections.txt Failed example: conn = db.open() Exception raised: Traceback (most recent call last): File "/opt/python/3.4.2/lib/python3.4/doctest.py", line 1324, in __run compileflags, 1), test.globs) File "<doctest historical_connections.txt[0]>", line 1, in <module> conn = db.open() File "/home/travis/build/zopefoundation/ZODB/src/ZODB/DB.py", line 761, in open self.historical_pool.availableGC() File "/home/travis/build/zopefoundation/ZODB/src/ZODB/DB.py", line 277, in availableGC for key, pool in self.pools.items(): RuntimeError: dictionary changed size during iteration
-
- 18 Mar, 2016 1 commit
-
-
Tres Seaver authored
Do3cc fix for45 master
-
- 17 Mar, 2016 3 commits
-
-
Patrick Gerken authored
-
Patrick Gerken authored
-
Patrick Gerken authored
-