jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Handling namespace mapppings
Date Thu, 29 Mar 2012 17:43:13 GMT

> I started drafting how namespace handling might look like in oak-jcr.
> See [1] for my initial draft based on the Oak API as it currently
> exists.
> Basically my idea is to have the namespace registry stored in some
> system location (like /:system/ns) and accessed over the standard Oak
> API.


> Some issues / ideas that came up:
> * I'm assuming that the Connection is per-repository. If it isn't, we
> need some other way to access repository-global data.

The current thinking is, it depends ;-) From RepositoryService.login you 
get a connection which is bound to the workspace. From that connection 
you can obtain a per repository connection.

> * Should we have a refresh() method on Connection that updates the
> getCurrentRoot() value or should the return value always reflect the
> latest state of the underlying repository? If the latter, we need some
> place in oak-jcr that keeps track of the current state of the
> repository as seen by a specific JCR Session.

I think a connection should be bound to a revision and update that 
revision at well defined points in time. For example after a commit on 
the connection succeeded. Along these lines, I think we need to add a 
refresh method. SessionImpl.refresh() currently does


as a workaround.

> * The NodeState interface in oak-mk explicitly doesn't understand
> anything about paths. Perhaps we should have a separate interface in
> the Oak API that does understand paths and can resolve them. Or
> perhaps have a utility class for dealing with path resolution? That
> would make the code in getRegistry() much simpler.

There is org.apache.jackrabbit.mk.util.PathUtils in oak-mk and 
org.apache.jackrabbit.oak.jcr.util.Path in oak-jcr which encapsulates 
the former. These might serve as a starting point.

> * The property.getScalar().getString() pattern quickly becomes
> cumbersome. A property.getString() method would be more convenient,
> especially if it also automatically deals with type conversion and has
> some reasonable default interpretation for multivalued properties
> (like returning just the first value or a concatenation of all
> values).

Generally property.getString() should just forward to scalar.getString() 
(where we need to define how to handle the binary case btw.). For multi 
valued property I'm not sure whether we really should abbreviate those. 
After all, we don't support 'big property lists' so the concatenation 
shouldn't be too big neither.

> * Do we want to deal with node types at this level, or should we
> simply declare that any nodes without an explicit "jcr:primaryType"
> property should be treated as if they were "nt:unstructured"? Not
> having to explicitly store typing information in such cases would save
> space and make things more convenient for many use cases (no need to
> explicitly exclude type information).

+1 for defaulting to nt:unstructured.


> [1] https://github.com/jukka/jackrabbit-oak/blob/7908756ec741a4ba331f174eb11e9c32be791324/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/OakNamespaceRegistry.java
> BR,
> Jukka Zitting

View raw message