jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Internal content in Oak
Date Thu, 12 Jul 2012 11:11:30 GMT

The discussion about orderable nodes (OAK-169) brought up a topic that
we'll be needing in a few other cases as well: How to handle extra
internal content that's needed to implement specific JCR features, but
that generally shouldn't be directly visible through the JCR API?

For example, the extra Oak-level property (or properties, depending on
how we implement the feature) needed to keep track of JCR-level node
ordering information needs to be available through the Oak API since
oak-jcr needs it in order to correctly implement JCR methods like
getNodes() or orderBefore(), but such extra properties shouldn't be
directly visible to JCR clients as that would break application-level
assumptions about node content and massively complicate node type

One approach that's been in the air so far is to use some built-in
"oak" namespace for such internal, and then filter out all content
under that namespace in the oak-jcr layer. However, I believe we'll
need such a namespace also for things that *are* visible to clients.
For example the proposed "oak:unstructured" node type (i.e.
"nt:unstructured" without orderable child nodes or same name siblings)
would need to be visible to JCR clients, and things like query index
configuration (OAK-178) fall in to the same category. Also, using a
"normal" JCR namespace introduces a potential conflict with existing
namespace prefixes.

So I was thinking of using an explicitly invalid JCR name pattern for
such internal content. A nice one would be the ":name" pattern that's
already used by the MicroKernel for the ":childNodeCount" and ":hash"
pseudo-properties. For example, the child ordering information in
OAK-169 could go to a ":childOrder" property that's visible through
the Oak API and understood by things like namespace and node type
validators. The oak-jcr component could then internally access and
manipulate such properties, while automatically filtering them out
from the set of content directly visible to the client.



Jukka Zitting

View raw message