Hi Robert, On 5 November 2015 at 22:58, Robert Munteanu <[email protected]> wrote:
> Hi Ian, > > On Fri, 2015-10-30 at 15:38 +0000, Ian Boston wrote: > > Hi, > > I am trying to enhance a multiplexing document store written > > initially by > > Robert Munteanu to support multiplexing of content under > > /jcr:system/** in > > particular the version store and the permissions store. I have a > > scheme > > that should theoretically work, encoding the target store in the > > entry name > > of the map key. > > > > However, it seems that DocumentNodeState (and hence > > DocumentNodeBuilder) > > objects created by a DocumentNodeStore get a reference to that > > DocumentNodeStore, bypassing any multiplexing document node store. > > This is > > all ok if all the calls relate to content in the same > > DocumentNodeStore, > > but as soon as anything performs a call into DocumentNodeStore that > > relates > > to a path not within that DocumentNodeStore the multiplexing breaks > > down. > > Code that reads and writes to /jcr:system/** does this. > > > > I have tried hacking the code to ensure that the reference to > > DocumentNodeStore is replaced by the MultiplexingDocumentNodeStore, > > however > > when I do that, MultiplexingDocumentNodeStore gets calls that have > > insufficient context to route to the correct DocumentNodeStore. I > > could > > hack some more, but if I do, anything that works is unlikely to be > > acceptable to Oak as a patch. > > Well, I can relate, as the DocumentStore multiplexing implementation > does have to be a little creative at times to find out the proper > store. > > Could you list (some of) the places where the > MultiplexingDocumentNodeStore does not have enough information to know > where to route the operation? Might be helpful as a starting point. > If I look at the DocumentStore API, it doesn't look too bad. Every method that targets a specific store, contains a key or uses an UpdateOp which contains a primary key. Assuming the store can always be derived from that primary key, everything should work. What's less clear is the implementation specific methods that are used within oak-core. I am reasonably certain that RDBDocumentStore and MongoDocumentStore make assumptions and call protected methods. I say, should work, assuming that every reference to a DocumentStore implementation can be replaced with a reference to the MultiplexingDocumentStore, so that all calls go via the Multiplexer and non go direct to the DocumentStore implementation. To do it properly will be a big patch to oak-core, and I haven't started to look at oak-lucene. There isn't a great deal of point in preparing that patch if the Oak committers don't want this. Best Regards Ian > > Thanks, > > Robert >
