Re: [dev] IStorage.lastOID() proposal (was Re: [dev] RFC IMVCCStorage everywhere (Move ZODB's MVCC to storage layer))

On Thu, 16 Jun 2016 23:04:55 +0200,
Julien Muchembled <[email protected]> wrote :
> To make things clearer, I restart from the beginning. Let's 3 source DBs, whose oid ranges are 0..19, 0..29 and 0..39. The destination DB maps as follows:
> - DB1: 0..19 -> 0..19
> - DB2: 0..29 -> 20..49
> - DB3: 0..39 -> 50..89
> Which means that the destination DB starts with last_oid=89 and the master node delivers new oids starting from 90.
> Clients can commit without having to wait that the migration (any access to something that is not migrating yet is translated to an access to a source DB).

...and client is writing to NEO of course, we do not write anything to
the DBx being merged.

> About aesthetics, I can say that initially NEO used UUIDs to identify nodes and that was painful to debug.

BTW, it occurred to me recently that maybe we only needed some
address-to-name translation in the log generator, while keeping the
internal data an UUID. Then, only very-low-level errors would need
actual UUID access.
Well, we have something which works without now, so it's not worth
going back to UUIDs anyway. They were likely overkill as process
identifiers. I will take the risk of saying "2**24 nodes ought to be
enough for anybody" with my tongue not so much in my cheek...
-- 
Vincent Pelletier
ERP5 - open source ERP/CRM for flexible enterprises

-- 
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.