[TransWarp] Cross-database stubs/copies using ZODB persistence

[Phillip J. Eby]

Scenario 1: DB-1 is primary, DB-2 keeps stubs only

Objects looked up from DB-1 may need to be referenced by objects in DB-2.
When the referencing object's state is saved, ask DB-2 for a "pointer"
value to be saved.  DB-2 detects that the object is in a foreign DB for
which it implements stubs, so it creates the stub and returns the stub's
key for reference in the referencing object's state.

When the referencing object is loaded, and it requests a ghost object for
the referenced object, DB-2 sees that it is a stub, and forwards the
request to DB-1, using the keys in the stub, putting a reference to the
"foreign" object in the loaded state.


Scenario 2: DB-1 is primary, DB-2 stores additional info on object

In this scenario, lookups on unique keys are handled by DB-2.  If DB-2 has
an object with the appropriate key values, doublecheck against DB-1 to
confirm that any copied keys or state are still valid, and update them if
not.  If DB-2 does not have an object matching the keys (or DB-2 does not
store that type of key), retrieve from DB-1, and match keys back to DB-2.
If a match is found, update DB-1 state in the DB-2 object, otherwise return
the DB-1 object.  Regardless of where the object is retrieved from, it
should end up with a _p_jar of DB-2, which will be responsible for saving
both parts of its state.

At save time, if there is no data in DB-2 for the object, but the object
has state which needs saving to DB-2, a new DB-2 _p_oid should be issued
and the DB-2 state created.

This scenario is probably simpler to think about and implement if you just
think of DB-1 and DB-2 as a single database (from the _p_jar POV), with
just parts of the state loaded and saved from different places.  This is
probably doable within some kind of "oid -> object" factory mechanism.
That is, one would register factories for DN oids, uid oids, UUID oids,
integer oids, and so on.