Reviving this old thread as I just started looking into this > 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.
Multiplexing is being implemented at DocumentStore level and DocumentNodeStore gets a reference to that. And that internally has a reference to MultiPlexingDocumentStore so logically looks ok > 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. Can you provide a testcase on Robert's branch illustrating the problem? That would help to understand the problem you are facing better Chetan Mehrotra On Fri, Oct 30, 2015 at 4:32 PM, Ian Boston <[email protected]> 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. > > Any suggestions ? > > I haven't even started to look at /oak:index and the code that writes/reads > from there. > > Best Regards > Ian
