GitLab

places.

DB._closeConnection() sets the connection's _db member to None now, under
protection of the lock it holds anyway.  At a deeper level, it's unclear
why _db keeps getting set and unset to begin with, but no time for that
now (and there are already XXX comments about it in the code).

Alas, I wasn't able to write a test that provoked the original bug in
finite time (it's a tiny timing hole), except via calling sleep() between
two lines that don't exist anymore.  Good enough.

an object as a non-negative integer.  Code trying to pass addresses to
an %x format uses positive_id(), and this avoids a Python FutureWarning
about applying %x to negative ints.  The primary difference between this
and the last stab is that positive_id() should work OK on 64-bit boxes
too.  What we really want here is C's %p format code, but in Python we
can't even reliably know the width of native addresses.

negative ints *as* negative ints when fed into %x formats.  Python 2.3
still renders them as positive ints, but spews

FutureWarning: %u/%o/%x/%X of negative int will return a signed string
               in Python 2.4 and up

to warn about the impending change.  Jim reported two instances of that
warning when running the tests on a box where addresses happen to "be
negative".  So make the addresses look positive instead (2.3 and 2.4
treat those the same, so 2.3 doesn't warn about those).

Problem:  it occurs to me now that I'm assuming addresses fit in 32
bits here.

This branch introduces a new transaction API.  The key features are:
  - top-level functions in transaction -- get(), commit(), abort()
  - explicit transaction manager objects
  - Transaction objects are used for exactly one transaction
  - support for transaction synchronizers

The changes here are still provisional, but we want to get them off an
obscure branch and onto the head for further development.

Make _added_during_commit a regular instance variable.  Don't use
try/finally to reset it; just clear it at the start of a transaction.
XXX There was a test that needed to be removed, but it seemed to be
just a shallow test that try/finally was used.  Can't see any feature
that depends on specific of error handling: The txn is going to abort.

Remove unused _opened instance variable.
Split commit() into two smaller parts.
Get rid of extra manipulation of _creating.
Don't look for _p_serial of None; z64 is now required.
Undo local variable aliases in subtransaction methods.

Also, trivial change to pickle cache API -- get() works like dict get().

It's clear in hindsight that the connection only loads non-current
revisions for objects that have been invalidated.  Thus, we never need
to track them to invalidate stale objects; they'll be invalidated
anyway.  And loadBefore() will never return a current revision,
because it would only be called if the current revision could not be
used.

Add a few comments.

Add docstrings for public cache methods.

If there is a jar and no oid, then the user assigned _p_jar directly.
All the Connection that assigns _p_jar also assigns an oid.

Import IPersistent so docstrings can refer to it.
Move $Id$ tag about @group tags so epydoc doesn't complain.
Don't return anything from _setDB().  The caller always has the object
    anyway.
Rename local variable in register() from object to obj to avoid
    shadowing builtin name.

Add get() as preferred synonym for __getitem__.  Change several uses
    of subscripting to get().
Change add() to register new object with transaction.
Change several methods to raise RuntimeError if they are called when
    the Connection is closed.
Add experimental epydoc markup to doc strings.
Extend doc strings and write new tests for "User Methods."

on the Zope 2 head. While I can appreciate the desire to unserstand
why register would be called by an object that has no _p_oid,
such questions should be answered in a sandbox, without breaking the
head.

revise words about registering with transactions.

Add support for persistent weak references.  The implementation is in
pure Python right now; coptimizations.c was disabled.  We need to
restore the C code before going to beta.

The persistent reference format has evolved a little, but the code on
the branch doesn't document it.  The ref is usually a an oid-class
pair, where the class is an actual class object.  It can also be a
list, for weak references, or a bare oid.

Add support for data managers written against the ZODB4 transaction
API.  The transaction implementation provides an adapter between the
two interfaces.  There's a substantial doctest test suite for this
feature.

Add add() method to Connection to explicitly add an object and get it
an assigned _p_oid.  It's possible to add an unconnected object; this
isn't recommended, because it will be lost at pack time.

The comment long ago fell out of synch with the code.

The Connection class inherits from the ExportImport mixin, but they
had an arm's length interaction.  Restructure the code to provide
direct interaction via the _import attribute.

Remove the more general onCommitCallback() method.  It was only used
by ExportImport.

A lot of cosmetic changes to ExportImport:
    - don't make local variables out of attribute lookups
    - avoid local variable names that shadow builtins
    - prefer isinstance() to type comparisons
    - prefer absolute imports to relative imports

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.

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.

problem is likely somewhere else, but I'm not going to stay up tonight
sorting this out.

docstring, this function never returned True.

The comment indicated that end could be None, and I've fleshed out the
comment with more detail.