Hi,
I think especially for document like structures, like
nt:hierarchyNode+jcr:content (eg: cq:Page+cq:PageContent) it makes
sense to store the subtree in one object, as such a document is
usually treated as 1 entity and all its subnodes are usually traversed
on read. IIRC, it was one of the
Hi,
The SegmentMK addresses this issue by grouping related content into
larger segments and thus reducing the number of network or disk
accesses needed in most use cases. Perhaps the MongoMK could do
something similar?
Yes. What might work is to store a limited number of child nodes (a
subtree
Hi,
Trying to restart an application like Adobe CQ running on Oak and
Mongo DB on a remote system takes considerable amount of time. In a
typical restart the number of such calls are around 23000 (Reduced
from 42000 with OAK-1117). I am trying to analyze the nature of calls
and also cache
Hi,
On Fri, Oct 25, 2013 at 11:32 AM, Chetan Mehrotra
chetan.mehro...@gmail.com wrote:
Thoughts?
All the suggested approaches seem reasonable.
More generally though, I think what you're seeing here is ultimately
an issue of granularity of access. You have a use case where the
client is
