On Tue, 2015-06-09 at 17:01 +0200, 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.
If your suggestion aims towards something like
@@ -59,7 +59,7 @@ public interface DocumentStore {
* @return the document, or null if not found
*/
@CheckForNull
- <T extends Document> T find(Collection<T> collection, String key);
+ <T extends Document> T find(Collection<T> collection, DocumentKey
key);
/**
* Get the document with the {@code key}. The implementation may
serve the
that would be a very invasive change which will propagate throughout
the Oak code base and also break backwards compatibility ( unless we
keep a set of deprecated methods alongside ) , neither of which seems
very nice.
Another possible approach is to have a DocumentKey class ( or
alternatively an interface backed by a DocumentKeyFactory class if you
prefer ), which can be used as follows
DocumentKey docKey = DocumentKey.from(String key);
log.info("Path is {}, depth is {}", docKey.getPath(),
docKey.getId());
Robert
