[dev] RFC IMVCCStorage everywhere (Move ZODB's MVCC to storage layer)

Jim Fulton <[email protected]>
Newsgroups gmane.comp.web.zope.zodb
Message-ID <CAPDm-Fg-XiS5=XcsCs1831D-VyycRuU91_bm1nba2RM8nPFJSw@mail.gmail.com>
I had some discussion with Shane and Jason about RelStorage and
learned some things. :)  I'd been puzzled by the fact that RelStorage
did MVCC when ZODB was also doing it and I've been annoyed by the
conditional logic in ZODB to special-case RelStorage.

What I learned is that RelStorage leverages the fact that the RDBMSs
already do MVCC and lets them do that lift rather than making ZODB do
it.  I think this makes perfect sense in this context. Given this,
forcing RelStorage to do MVCC using ZODB doesn't make sense.

What makes more sense is to split ZODB's MVCC support into a separate
layer that's applied to storages **other than** RelStorage as an
adapter.  When a database is created, it will check if a storage
provides IMVCCStorage. If it doesn't, it will apply an adapter to it
that does.  Connection will assume that it has an IMVCCStorage and act
accordingly.

The current invalidation and transaction time logic will move to the
IMVCCStorage adapter.

This is an evolution of the ZODB5 work I've been doing. The load
method is still replaced by loadBefore in IStorage, but remains in
IMVCCStorage and is called by connections.

In the long run, I think IMVCCStorage could use some refinement.  I'd
like to see a cleaner separation from IStorage. I'd also like
new_instance to accept a before argument to facilitate time travel.

I don't think I'm going to do this right now. Getting invalidations
right might be kind of tricky and there are too many other pans on the
fire right now, at least for me, to add this.

Jim

-- 
Jim Fulton
http://jimfulton.info

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.