- 12 Oct, 2004 1 commit
-
-
Andreas Jung authored
-
- 11 Oct, 2004 1 commit
-
-
Andreas Jung authored
variable was included into the generated query if the 'optional' flag inside dtml-sqltest was set an if the value of the string was empty.
-
- 10 Oct, 2004 1 commit
-
-
Chris McDonough authored
Collector #1350: segfaults under SessionRig stress tester. Since we perform a unfortunate monkey-patch in here to ZODB's Connection class, and in doing so we override the "close" method of that class, we need to do all of the things that ZODB 3.3's "close" method does, which includes unregistering a synchronizer.
-
- 09 Oct, 2004 1 commit
-
-
Tres Seaver authored
-
- 08 Oct, 2004 2 commits
-
-
Tim Peters authored
The Python fatal errors occur only in a debug build now. In a release build, unghostify() raises a Python SystemError exception if it detects insanity, and ghostify() ignores the problem (as ZODB 3.2 did, although it looks like 3.2 ignored the problem by mistake). This isn't *good*, because the system is insane. But it can become insane only by breaking absolute threading rules, and that "should never happen". Unfortunately, hundreds of things can go wrong if it does happen, and we can't detect most of them.
-
Tim Peters authored
In ghostify() and unghostify(), trigger a fatal error if the object is insane. This prevents a segfault (or, worse, arbitrary memory corruption) later. The test suite isn't bothered by this, and neither is bringing up a Zope and playing around with it. The only known cause appears to be threading problems related to Transience.py, partly explained in issue #1350. It should be impossible for these fatal errors to trigger via thread-correct use of ZODB. I don't expect to keep these fatal errors in the code; indeed, I'm checking this in only in Zope's *copy* of ZODB. The intent is to help whoever can make time for 1350 know whether that problem still exists, until that problem goes away. Unfortunately, it's not even possible to raise an exception from ghostify() (it's a void routine that "can't fail"), so it takes an extreme measure to catch the problem as soon as it's visible.
-
- 06 Oct, 2004 2 commits
-
-
Tim Peters authored
- 05 Oct, 2004 2 commits
-
-
Tim Peters authored
-
Tim Peters authored
-
- 04 Oct, 2004 3 commits
-
-
Tim Peters authored
Changing to pickle protocol 2 has severe backward compatibility implications; changes to ZODB should not be made from the Zope trunk regardless.
-
Stefan H. Holek authored
-
Stefan H. Holek authored
-
- 01 Oct, 2004 2 commits
-
-
Stefan H. Holek authored
-
Andreas Jung authored
-
- 30 Sep, 2004 7 commits
-
-
Jim Fulton authored
-
Tim Peters authored
FileStorage.history() was reading the user, description, and extension fields out of the object pickle, due to starting the read at a wrong location.
-
Andreas Jung authored
-
Andreas Jung authored
store history informations. In ZODB 2.8 'tid' is used. At least the management screen is showing up again however the 'description' value shows only garbage. Also there might a problem with backward compatibility.
-
Andreas Jung authored
- Re-added the DAV header (Collector #1518) which had been removed in beta 1.
-
Tim Peters authored
Restored the ._opened attribute of Connection. Don't know why it went away in 3.3. Probably because it was only referenced by connectionDebugInfo(), and Jeremy didn't realize anyone used that <wink>.
-
Tim Peters authored
The DB.cacheStatistics() method was introduced in DB.py rev 1.2, and has always returned an empty tuple. A number of "never did anything, probably never will" DB methods like that were removed in ZODB 3.3, to reduce stumbling over decoys. That was discussed on zodb-dev at the time, with universal agreement to get rid of them. So the resolution in this case is changing Zope to stop trying to access the no-longer-extant cacheStatistics() method. If someone doesn't like this, they can revert this patch, then change App/CacheManager.py's cacheStatistics() to return a hard coded empty tuple <wink>.
-
- 28 Sep, 2004 3 commits
-
-
Tim Peters authored
Caution: Since no deprecation warnings about Transaction.begin() were raised by the test suite before this patch, none of this code is exercised by the test suite -- or it is, but "something" suppresses the deprecation warnings. So it's hard to claim that this patch has been tested; the strongest claim I can make is that all the unit tests still pass.
-
Florent Guillaume authored
-
Stefan H. Holek authored
-
- 27 Sep, 2004 3 commits
-
-
Tim Peters authored
-
Tim Peters authored
-
Tim Peters authored
1. a_Transaction_object.begin() is deprecated. Don't use it. 2. Commit failure is "sticky" now: the current transaction must be explicitly discarded (abort() or begin()) before a commit can succeed again.
-
- 25 Sep, 2004 2 commits
-
-
Chris Withers authored
Collector #1457: ZCTextIndex's QueryError and ParseError are now available for import from untrusted code.
-
Chris Withers authored
-
- 23 Sep, 2004 1 commit
-
-
Andreas Jung authored
- Collector #1491: talgettext.py did not create a proper header for the generated .pot file if multiple pagetemplate files were processed.
-
- 18 Sep, 2004 2 commits
-
-
Michael Dunstan authored
- Updated to use transaction.commit() rather than get_transaction().commit()
-
Chris McDonough authored
-
- 17 Sep, 2004 1 commit
-
-
Tres Seaver authored
-
- 10 Sep, 2004 2 commits
-
-
Andreas Jung authored
-
Andreas Jung authored
same signature as str.strip()
-
- 08 Sep, 2004 3 commits
-
-
Andreas Jung authored
-
Andreas Jung authored
-
Andreas Jung authored
-
- 06 Sep, 2004 1 commit
-
-
Andreas Jung authored
No commit message
-