1. 20 Mar, 2005 8 commits
  2. 19 Mar, 2005 7 commits
  3. 17 Mar, 2005 2 commits
    • Tim Peters's avatar
      Merge rev 29532 from 3.3 branch. · 63690564
      Tim Peters authored
      Merge checkin made from a wrong project:
      
      r29511 | gotcha | 2005-03-16 11:01:21 -0500 (Wed, 16 Mar 2005) | 1 line
      Changed paths:
         M /Zope/trunk/utilities/ZODBTools/zodbload.py
      
      port features from 2.7
      63690564
    • Tim Peters's avatar
      Merge checkin made from a wrong project: · 987573fc
      Tim Peters authored
      r29511 | gotcha | 2005-03-16 11:01:21 -0500 (Wed, 16 Mar 2005) | 1 line
      Changed paths:
         M /Zope/trunk/utilities/ZODBTools/zodbload.py
      
      port features from 2.7
      987573fc
  4. 14 Mar, 2005 2 commits
    • Tim Peters's avatar
      Merge rev 29467 from 3.3 branch. · 921617b8
      Tim Peters authored
      Backward compatibility hack for ZODB.Persistent{List,Mapping}.
      
      Allow those old (ZODB 3.2) dotted paths to work again.
      
      Fallout:  testPersistentMapping.py hasn't actually run anything
      for a long time, due to a mysterious "return None" at the start
      of its test_suite() function.  Removed that.  Then its
      checkNewPicklesAreSafe test failed.  Spent 15 minutes on that,
      and gave up -- I'm still not even sure what it's _trying_ to
      test.  Changed it to a TODO.
      921617b8
    • Tim Peters's avatar
      Backward compatibility hack for ZODB.Persistent{List,Mapping}. · d46b8017
      Tim Peters authored
      Allow those old (ZODB 3.2) dotted paths to work again.
      
      Fallout:  testPersistentMapping.py hasn't actually run anything
      for a long time, due to a mysterious "return None" at the start
      of its test_suite() function.  Removed that.  Then its
      checkNewPicklesAreSafe test failed.  Spent 15 minutes on that,
      and gave up -- I'm still not even sure what it's _trying_ to
      test.  Changed it to a TODO.
      d46b8017
  5. 12 Mar, 2005 1 commit
  6. 11 Mar, 2005 5 commits
  7. 07 Mar, 2005 2 commits
  8. 03 Mar, 2005 1 commit
    • Tim Peters's avatar
      Merge ZODB trunk changes checked in from a wrong project. · 2d90abbd
      Tim Peters authored
      r29290 | frerich | 2005-02-24 17:36:00 -0500 (Thu, 24 Feb 2005)
      Changed paths:
         M /Zope3/trunk/src/ZODB/tests/dbopen.txt
         ...
         minor editing
      
      r29247 | gintautasm | 2005-02-22 06:40:26 -0500 (Tue, 22 Feb 2005)
      Changed paths:
         M /Zope3/trunk/src/BTrees/Interfaces.py
         ...
         More minor nitpicks.  This should be the last one.
      
      2d90abbd
  9. 02 Mar, 2005 3 commits
  10. 01 Mar, 2005 2 commits
  11. 28 Feb, 2005 2 commits
    • Tim Peters's avatar
      Merge rev 29350 from ZODB 3.3 branch. · 1f6caf72
      Tim Peters authored
      Port from ZODB 3.2.
      
      Change FileStorage .restore() and .store() to update max oid in use.
      
      This is the last of the checkins to fix critical bugs involving rare cases
      where a FileStorage could end up reusing old oids for new objects.
      1f6caf72
    • Tim Peters's avatar
      Port from ZODB 3.2. · 7c89220e
      Tim Peters authored
      Change FileStorage .restore() and .store() to update max oid in use.
      
      This is the last of the checkins to fix critical bugs involving rare cases
      where a FileStorage could end up reusing old oids for new objects.
      7c89220e
  12. 25 Feb, 2005 2 commits
    • Tim Peters's avatar
      Merge rev 29302 from 3.3 branch. · 1fa059d1
      Tim Peters authored
      Port from ZODB 3.2.
      
      Stop believing the maximum oid cached in a FileStorage's .index file.
      
      This is a critical bugfix, although the problems it addresses are
      (a) rare; and, (b) not entirely fixed yet (more checkins to come).
      
      The true max oid is found efficiently now by exploiting the recently-added
      fsIndex.maxKey() method (which was, of course, added for this purpose).
      
      Also fix that the .index file could get updated on disk when the
      FileStorage was opened in read-only mode.  The code was trying to prevent
      this, but missed the most obvious rewrite path.
      
      Incidentally improved many obsolete and/or incorrect comments.
      1fa059d1
    • Tim Peters's avatar
      Port from ZODB 3.2. · 2a475c54
      Tim Peters authored
      Stop believing the maximum oid cached in a FileStorage's .index file.
      
      This is a critical bugfix, although the problems it addresses are
      (a) rare; and, (b) not entirely fixed yet (more checkins to come).
      
      The true max oid is found efficiently now by exploiting the recently-added
      fsIndex.maxKey() method (which was, of course, added for this purpose).
      
      Also fix that the .index file could get updated on disk when the
      FileStorage was opened in read-only mode.  The code was trying to prevent
      this, but missed the most obvious rewrite path.
      
      Incidentally improved many obsolete and/or incorrect comments.
      2a475c54
  13. 24 Feb, 2005 3 commits
    • Tim Peters's avatar
      Merge rev 29291 from ZODB 3.3 branch. · 90d19515
      Tim Peters authored
      Port from ZODB 3.2.
      
      Give fsIndex an efficient maxKey() implementation.
      
      This will (in a later checkin) be used to give FileStorage an "obviously
      correct" way to determine the largest oid used in an .fs.index file.
      90d19515
    • Tim Peters's avatar
      Port from ZODB 3.2. · 59907222
      Tim Peters authored
      Give fsIndex an efficient maxKey() implementation.
      
      This will (in a later checkin) be used to give FileStorage an "obviously
      correct" way to determine the largest oid used in an .fs.index file.
      59907222
    • Tim Peters's avatar
      Merge rev 29286 from ZODB 3.3 branch. · 1b1b18d7
      Tim Peters authored
      Port from ZODB 3.2.
      
      Note that cPickleCache.c must be recompiled else the new test will fail.
      
      Change the exception raised when an attempt is made to add two objects to
      the cache with the same oid.  The former messsage didn't make sense.
      
      Add a test to verify that this exception does get raised, and that the
      message given is the intended one.
      
      This is the first of a series of checkins, to fix critical bugs where
      ZODB can in fact raise this exception in rare, but normal, use cases.
      1b1b18d7