An error occurred fetching the project authors.
- 02 Jun, 2004 1 commit
-
-
Jim Fulton authored
-
- 30 Apr, 2004 1 commit
-
-
Tim Peters authored
"sporadic Zope crashes" http://collector.zope.org/Zope/553 This is much like the test of the same name I just added to the Zope 2.6 and 2.7 branches, but reworded to use ZODB 3.3isms. The HEAD bucket conflict resolution code is already correct in this case, so no other code change here -- adding this test to ensure it stays correct.
-
- 16 Apr, 2004 1 commit
-
-
Jeremy Hylton authored
-
- 14 Apr, 2004 1 commit
-
-
Jeremy Hylton authored
This changes the behavior slightly for invalidations. A Connection will receive invalidations even if it didn't have any modified objects in the transaction, e.g. db.undo() or a read-only transaction. For this to work, it assumes that the thread that called db.open() is the thread that is going to use the connection. If this isn't true, the synch argument to db.open() can be used to disable the new feature.
-
- 29 Dec, 2003 1 commit
-
-
Tim Peters authored
-
- 28 Nov, 2003 1 commit
-
-
Jim Fulton authored
-
- 24 Apr, 2003 1 commit
-
-
Jeremy Hylton authored
-
- 17 Jan, 2003 1 commit
-
-
Tim Peters authored
+ Transaction T1 deletes some of the keys in bucket B, but not all of the keys. + Transaction T2 deletes (exactly) the keys in B that aren't deleted by T1. The version of B each transaction sees is then non-empty, but conflict resolution creates an empty bucket. However, conflict resolution doesn't have enough info to unlink an empty bucket from its containing BTree correctly. The result is that an empty bucket is left in the BTree, which violates a BTree invariant. The most probable symptom is a segfault, when later & unrelated code tries to access this bucket: an empty bucket has NULL pointers where the vectors of keys and values should be, and accessing code tries to dereference the NULL pointers. I don't know that this error has been seen in real life. It was provoked by a randomized multithreaded simulation program that was trying to provoke errors. This error was provoked frequently by that program; no other kinds of errors have come out of it.
-
- 16 Jan, 2003 1 commit
-
-
Tim Peters authored
Zope3/ZODB4. Many test fixes from Jeremy (in particular, most of the tests weren't getting run), and new tests from Tim. Note that the new testEmptyBucketConflict() actually shows that a particular rare case of conflict resolution doesn't work correctly now. A fix for that comes next, along with reversing the sense of this new test.
-
- 14 Aug, 2002 1 commit
-
-
Martijn Pieters authored
-
- 28 Mar, 2002 1 commit
-
-
Jeremy Hylton authored
The problem was that the randomly generated test data was occasionally invalid. Fix is to hardcode a specific set of test data instead of using random.
-
- 11 Feb, 2002 1 commit
-
-
Guido van Rossum authored
-
- 28 Nov, 2001 1 commit
-
-
matt@zope.com authored
-
- 19 Oct, 2001 1 commit
-
-
Andreas Jung authored
-
- 26 Sep, 2001 1 commit
-
-
Jeremy Hylton authored
The only exceptions that an _p_resolveConflict() method should raise are ConflictError and ValueError. If it raises a different exception, then it has failed. In general, a unittest should not use a bare except clause, because they almost always mask failures. If the test really means to catch all exceptions, it's best to make a comment to that effect.
-
- 20 Sep, 2001 1 commit
-
-
Jeremy Hylton authored
-
- 14 Aug, 2001 1 commit
-
-
Jeffrey Shell authored
-
- 07 Aug, 2001 1 commit
-
-
Jeremy Hylton authored
The testrunner reports all tests passed after these changes. Remove unnecessary path munging and attempts to import ZODB. Update uses of whrandom to use random.
-
- 06 Aug, 2001 2 commits
-
-
Jeremy Hylton authored
-
Jeremy Hylton authored
-
- 15 Mar, 2001 1 commit
-
-
Jim Fulton authored
-