On 2015-06-15 17:11, Robert Munteanu wrote:
On Wed, 2015-06-10 at 10:13 +0000, Marcel Reutegger wrote:
maybe CachingDocumentStore is misleading and we would rather
name it HierarchicalDocumentStore, which also implements caching
and leverage hierarchical information for invalidation as needed.
HierarchicalDocumentStore would extend DocumentStore and
introduce new methods for NODES collection related operations
with the proposed DocumentKey (or similar).
I've iterated a bit on the design, and this is what I think is a good
starting point ( feel free to shout if you see anything blatantly wrong
with it, but I think it's good enough to start a POC with ).
interface HierarchicalDocumentStore extends DocumentStore
- adds findDocument/queryDocument/etc methods based on the DocumentKey
abstraction
CachingDocumentStore implements HierarchicalDocumentStore
- implements caching for the nodes collection based on the DocumentKey
abstraction ; caching logic is ported from existing MongoDocumentStore
( will also review the RDBDocumentStore logic )
- typically wraps another DocumentStore, like the MongoDocumentStore
and RDBDocumentStore
...
We've been there before. The issue here is that the logic for
refreshing/invaliding cache entries is spread out through the
persistence calls, and I don't believe that layering it above will be
equivalent.
Maybe a better approach would be to refactor the caching to it can be
used as a common utility class.
See also <https://issues.apache.org/jira/browse/OAK-1940>.
Best regards, Julian
