MultipleSimultaneousStorage

Proposal: MultipleSimultaneousStorage

Initiator: Jason Spisak

This is really a carry over from the MultiFileStorage proposal that approaches the problem from another angle.

Jim

I'm not sure what problem you're trying to solve. It seems you simply want to spread storage over multiple physical storage mechanisms. Is that right? What if the storage as have different semantics? Should the resulting storage have the least common denominator semantics?

Jim

See MountedDatabases

The root object in a ZODB is required. This has to be creatively statified in order to allow multiple storages of any kind ( RelationalStorage , FileStorage ) to be used together to form a coherent object hirearchy without modifying the ZODB. The root object would be responsilbe for presenting the ZODB with a set of objects that looks like a single storage. By separating the StorageManager from the ZODB you gain storage modularity, and the existing interface to the ZODB can remain constant.

• Short Term Goal

  I have no idea how to accomplish this but, here it goes. To have the root object of the ZODB come from another Python object, and not a hard coded element. This middleman object hands the ZODB a standard Data.fs file. The Python middleman object would be the StorageManager.

  • Medium Term Goal

    Have two the Data.fs become 2 files. Split at an arbitrary location, and have the StorageManager merge the two before handing it to the ZODB. Or even better, the StorageManager could know where to look for an oid in a registry of somekind.

    • Long Range Goal

      World Peace.

      • Final Goal

        Have multiple storages register themselves with the StorageManager, and provide a consistant set of objects to the ZODB.