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
Hi,

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
handling.

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.

WDYT?

BR,

Jukka Zitting

Mime
View raw message