This allows us to not worry about method overriding and avoids
creating wrapper methods (some of which were broken).

My guess is that performance is a wash.  We take a tiny hit on the
first access, because ``__getattr__``, but we don't have to copy
methods we never use.

It wasn't really needed or used and caused a stupid ZEO test failure.

I do think the storage API needs to be thought about and refined at
some point, but now, it's not a priority.

I'd lazily assumed that undo and tpc_vote has the same sorts of
returns, but they don't.  When tpc_vote isn't None (ZEO), the retrun
is a list of oid and serial pairs.

To prevent modifying the set of instances while iterating over them.

That's applied to storages other than RelStorage.

See: https://groups.google.com/forum/#!topic/zodb/QJYmvF0eUUM

And in special case where a connectin is opened while a transaction is
active (Zope2).

It's too hard to remember to update the meta data (we've been in beta
for a long long time).

By resetting self.__onCloseCallbacks before calling the close
callbacks to forestall infinite recursion (as can be the case when a
close callback is the database close methos).

Changed it to the value corresponding to the maximim *signed*
big-endian 64-bit integer, because of LxBTrees.

Note that this value isn't used anywhere in ZODB yet.

Maybe it should be.

To mitigate errors during tearDown.

Lots of tests are sloppy about closing connection (because they could
be), but storages tend to get closed and transactions aborted. This
has the effedt of calling afterCompletion on connections which tries
to call storage lastTransaction, which causes errors.

Fixed: FileStorage loadBefore didn't handle deleted/undone data correctly

Enforce minimum required Python versions: 2.7, 3.3.

+1

Merge pull request #62 from zopefoundation/dont-depend-on-implementation-detail-in-tpc_finish-test-assertions

Fixed a test that depended on some off behavior of tpc_finish in some…

This and https://github.com/zodb/relstorage/pull/31 make RelStorage
pass with this branch (as much as they pass with master).

Closes #59.

This answers #13

- It failed with oids that already exist in the base storage.
- MappingStorage returned timestamps in wrong format.

On Python 2 and Mac OS X, checkFlushAfterTruncate was failing.

Even though the previous commit otherwise made MVCCMappingStorage and
IMVCCStorage handling better.

The previous commit, made in anger, made a test pass, but wasn't
really the right fix.

This commit fixes MVCCMappingStorage's loadBefore implementation by
fixing handling of the internal _ltid variable so that it's updated
during poll_invalidations.  This allowed the base class version of
loadBefore to be used and, I'm 97% sure has the right semantics.
Fixing this revealed a problem with the Connection changes.

Fixed Connection.py to poll for invalidations before computing
_txn_time by calling lastTransaction, so as to get a current value.
We still apply invalidations after computing _txn_time, so that
persistent classes can be loaded correctly when they are invalidated.
This was accomplished by weaving _flush_invalidations into
newTransaction.

Changed to always empty the file pool.  I doubt that just flushing on
Python 2 was much of an optimization, and ... Python 2. :)

This is needed because pack temporarily deletes data from the data
structure that loadBefore reads.

Note that in the new scheme of things, we avoid using load, but
instead use loadBefore.  This we bypass the _data_snapshot
shenanigans, which makes me think we aren't testing what we should be,
but I have no confidence that the machinery in MVCCMappingStorage
actually reflects anything meaningful.