See http://stackoverflow.com/questions/9153473/sphinx-values-for-attributes-reported-as-none/39276413

To avoid tearDown issues on Windows.

(The reason for moving it below seems to have gone away.)

checkTransactionalUndoIterator: do not expect iterator to return sorted oids

fstail: print the txn offset and header size, instead of only the data offset

Drop old commit protocol

Changed DB root-object-initialization to use an open connection and more

Tp get predictiable time specing to avoid spurious failures.

This fixes #84.

Also:

- Added missing transaction ``begin`` call in the DB ``transaction()``
  context manager.

- Added the ability to add a transaction note whan calling
  ``transaction()``.  This is useful (as would be the ability to pass
  in other transaction meta data, but this was needed by (and this
  tested) to make an existing test pass.

There's no reason to care.

(And a change in db root-object setup shifted the old test times.)

Added a connection prefetch method

Cus there's no such thing as an optional method in interfaces.

  that a storage prefect data an application will need::

    conn.prefetch(obj, ...)

  Where arguments can be objects, object ids, or iterables of objects
  or object ids.

  Added optional prefetch methods to the storage APIs. If a
  storage doesn't support prefetch, then the connection prefetch
  method is a noop.

Fix testMinimizeTerminates

This test was spewing exceptions without failing for ZODB5.

The spew was an indication that something was wrong in this case. (The
test was broken.)

There had been some bug in the object cache that caused an infinite
loop when objects woke themselves up while being reaped.  This test is
a regression test for that bug.

The test was sloppy about transaction managers.  The test class
creates a bunch of connections using the threaded transaction manager,
but this test used a thread to execute the critical code.  As a
result, the synchronization methods weren't called.  This didn't
matter much with ZODB4.  The objects were still able to load their
state.

With ZODB5, the synchronization methods are important for proper MVCC
and because they weren't called, the objects' state couldn't be
reloaded, with 2 effects:

- Spew

- The test wasn't really testing that object's that reloaded
  themselves didn't create an infinite loop.

Changed the test to not use a threaded transaction manager.

Before:

    2016-07-01 09:41:50.416574: hash=d7101c5ee7b8e412d7b6d54873204421e09b7f34
    user='' description='' length=1629 offset=58990284

After:

    2016-07-01 09:41:50.416574: hash=d7101c5ee7b8e412d7b6d54873204421e09b7f34
    user='' description='' length=1629 offset=58990261 (+23)

The structure of a FileStorage DB is such that it's easy to revert the last
transactions, by truncating the file at the right offset. With the above
change, `fstail` can now be used to get this offset.

In the above example:

    truncate -s 58990261 Data.fs

would delete the transaction and all those after.

As part of a project to provide object-level commit locks for ZEO, I'm
refactiring FileStorage to maintain transaction-specific data in
Tranaction.data.  This involved undo.  In trying to figure this out, I
found:

- A bug in _undoDataInfo, which I verified with some tests and

- _transactionalUndoRecord was maddeningly difficult to reason about
  (and thus change).

I was concerned less by the bug than my inability to know whether a
change to the code would be correct.

So I refactored the code, mainly transactionalUndoRecord, to make the
code easier to understand, fixing some logic errors (I'm pretty sure)
along the way.  This included lots of comments. (Comments are much
easier to compose when you're working out logic you didn't
understand.)

In addition to makeing the code cleaner, it allows undo to be handled
in cases that weren't handled before.

Refactored FileStorage transactional undo

Per @jimfulton, handle_all_serials shouldn't be sniffing in ZODB5

Thanks.

Fix handle_all_serials for the new and old protocols.

As part of a project to provide object-level commit locks for ZEO, I'm
refactiring FileStorage to maintain transaction-specific data in
Tranaction.data.  This involved undo.  In trying to figure this out, I
found:

- A bug in _undoDataInfo, which I verified with some tests and

- _transactionalUndoRecord was maddeningly difficult to reason about
  (and thus change).

I was concerned less by the bug than my inability to know whether a
change to the code would be correct.

So I refactored the code, mainly transactionalUndoRecord, to make the
code easier to understand, fixing some logic errors (I'm pretty sure)
along the way.  This included lots of comments. (Comments are much
easier to compose when you're working out logic you didn't
understand.)

In addition to makeing the code cleaner, it allows undo to be handled
in cases that weren't handled before.