Hi,
On Wed, 2015-06-10 at 06:47 +0000, Marcel Reutegger wrote:
> Hi,
>
> I would rather like to keep the DocumentStore as simple as possible.
> Ideally an implementation wouldn¹t have to deal with caching.
> See OAK-1328. Caching and knowledge about the hierarchical structure
> would be implemented on a higher level.
In my initial POC the DocumentStore interface would not be modified.
The only assumption regarding parsing keys would live in the
MultiplexingDocumentStore, which is an implementation, not API.
The (incomplete) code would look something like the following
@Override
public <T extends Document> T find(Collection<T> collection, String
key) {
DocumentStore store = findBestMatchingStore(key);
return store.find(collection, key);
}
where findBestMatchingStore tries to find the DocumentStore which
'owns' the specific key, based on the most specific ancestor path.
I looked at OAK-1328, but it does not list any implementation ideas.
Where would you see these hierarchical concerns best addressed?
Thanks,
Robert
>
> On 09/06/15 17:01, "Julian Reschke" wrote:
>
> > On 2015-06-09 16:41, Ian Boston wrote:
> > > Hi,
> > > Should the opaque String key be abstracted into a DocumentKey
> > > interface
> > > so
> > > that how the key is interpreted, and how it might be associated
> > > with a
> > > certain type of storage can be abstracted as well, rather than
> > > relying
> > > on
> > > some out of band specification of the key to be serialised and
> > > parsed at
> > > every transition ?
> > > Best Regards
> > > Ian
> > > ...
> >
> > Absolutely.
> >
> > That would also be relevant for some some parts of the
> > MongoDocumentStore implementation which currently make assumptions
> > about
> > ID structure for cache invalidation purposes.
> >
> > Best regards, Julian
> >
>
