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

On Thu, Jun 16, 2016 at 10:43 AM, Julien Muchembled <[email protected]> wrote:
> Le 06/16/16 14:46, Jim Fulton a écrit :
>>> I'm not enthusiast with so many lines of glue code and extra function calls.
>>
>> I don't think there are more lines of code or more function calls. The
>> MVCCAdapter work just moved some code around.
>
> 1. It's one layer of dummy function calls. For example, newTransaction called storage.sync() directly, and now it would call adapter.sync() which would in turn call storage.sync(). Same for load and other storage methods.

Most methods are copied.  The only two of consequence are sync and
load.  I hope that we can eventually get rid of the argument to sync,
at which point, it can just be copied too.  The extra level call is
unavoidable if you want to separate MVCC, which I do for 2 reasons:

1. It's important to cal load for RelStorage, which lets the backend
database engine take care of MVCC. Doing MVCC in ZODB doesn't make
much sense if you're already using a database backend that does it.

2. Separation of concerns.

>
> 2. more lines of code, mainly to copy attributes, also some registerDB logic
>
> Generally speaking, I find the whole result more complex than just seeing Connection code calling methods directly on the real storage, and if the storage does not overload, look at the inherited mixin.

I have a lot of sympathy for this point of view. ZODB and ZEO use lots
of unnecessary indirections that I'm slowly stripping.  Overall, ZODB5
remove quite a bit.

...

>> I don't consider ConflictResolvingStorage a success story. Generally,
>> I don't like providing public inheritance APIs. Conflict resolution
>> would have been better provided via composition.
>
> (Taste and colours...)

:) Fair enough.

>
> I see there's also BlobStorageMixin.

Yes, but that's mainly used internally to implement FileStorage and
BlobStorage.  The later is intended to be used via composition.

>
>> Of course, there's nothing preventing any storage implementation from
>> implementing IMVCCStorage other than the fact that IMVCCStorage needs
>> more thought.
>
> And in the case NEO, that consists in duplicating code from mvccadapter.py

Perhaps, although I would expect if you implemented IMVCCStorage,
you'd end up with very different code.  You wouldn't have method
copying. You'd probably combine load and loadBefore, and so on.

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.