- 06 Jan, 2004 10 commits
-
-
Jeremy Hylton authored
-
Jeremy Hylton authored
-
Tim Peters authored
-
Jeremy Hylton authored
In the branches that call loadBefore() or raise ConflictError, make sure we always return. Either case satisfies the original call to setstate() and we don't want to load the current state.
-
Fred Drake authored
ZConfig.components.logger, adding only what's special about the zLOG version of the factory
-
Jeremy Hylton authored
-
Jeremy Hylton authored
Bug reported by Dieter Maurer. The change required several of the read-conflict tests to be updated to specify that they don't want MVCC support. It was basically accidental that they passed before this change. Note that we don't have any tests of code that gets a read conflict in MVCC mode, which would only be possible after a pack() or in some other weird case.
-
Jeremy Hylton authored
-
Tim Peters authored
problem is likely somewhere else, but I'm not going to stay up tonight sorting this out.
-
Tim Peters authored
docstring, this function never returned True.
-
- 05 Jan, 2004 8 commits
-
-
Fred Drake authored
- time-interval values are the number of seconds
-
Tim Peters authored
-
Jeremy Hylton authored
-
Tim Peters authored
BTrees.check module and to the BTree._check() method.
-
Tim Peters authored
-
Fred Drake authored
ZConfig.logger.log type, since it does
-
Fred Drake authored
the logging package; this avoids lots of code duplication
-
Jeremy Hylton authored
This old script was provided in 3.2 only to ease transition. Removed now, because it depends on zdaemon.Daemon, which no longer exists.
-
- 02 Jan, 2004 15 commits
-
-
Jeremy Hylton authored
-
Jeremy Hylton authored
-
Jeremy Hylton authored
-
Jeremy Hylton authored
-
Jeremy Hylton authored
-
Fred Drake authored
-
Fred Drake authored
-
Jeremy Hylton authored
-
Jeremy Hylton authored
The last tid is already set as a result of the invalidate() calls made in _update_cache().
-
Fred Drake authored
-
Tim Peters authored
previous one" check fails. Surprise! The test was using tid < self.tid, not <=, so it can't be the case that the test was failing because the new tid was equal to the last one. Changed the test to use <=. Maybe that's not a good change, but, if not, then the error message is wrong <wink>.
-
Fred Drake authored
-
Fred Drake authored
<import>
-
Fred Drake authored
-
Fred Drake authored
-
- 01 Jan, 2004 1 commit
-
-
Fred Drake authored
-
- 31 Dec, 2003 4 commits
-
-
Jeremy Hylton authored
Connection initialized _map as a dict containing a single entry mapping the connection's fileno to the connection. That was a misuse of the _map variable, which is also used by the asyncore.dispatcher base class to indicate whether the dispatcher users the default socket_map or a custom socket_map. A recent change to asyncore caused it to use _map in its add_channel() and del_channel() methods, which presumes to be a bug fix (may get ported to 2.3). That causes our dubious use of _map to be a problem, because we also put the Connections in the global socket_map. The new asyncore won't remove it from the global socket map, because it has a custom _map. Also change a bunch of 0/1s to False/Trues.
-
Fred Drake authored
applications to know less about how this is implemented
-
Fred Drake authored
-
Jeremy Hylton authored
The comment indicated that end could be None, and I've fleshed out the comment with more detail.
-
- 30 Dec, 2003 2 commits
-
-
Jeremy Hylton authored
Move setLastTid() call into block where lock is held.
-
Jeremy Hylton authored
-