[
https://issues.apache.org/jira/browse/OAK-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-203:
------------------------------
Attachment: OAK-203.patch
There has been some recent discussions about "basic SNS" in Oak not being
usable \[1], \[2].
Oak currently creates nodes with an index expression while upgrading from
Jackrabbit and internally to expose the node type definitions as content. In
both cases there is nothing that could be done to such nodes through the JCR
API as even retrieving them will throw a {{PathNotFoundException:
sibling\[42]}} or some variant thereof.
The attached path addresses this by allowing index expressions on the path for
read access. This way users can work with such nodes as with any other nodes
but can't create new "SNS" nodes themselves.
\[1] http://markmail.org/message/qge5nnyev3hzzipx
\[2] http://markmail.org/message/7qczhkpicvq7q5ea
> Basic same name sibling support
> -------------------------------
>
> Key: OAK-203
> URL: https://issues.apache.org/jira/browse/OAK-203
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
> Reporter: Jukka Zitting
> Priority: Minor
> Fix For: 1.1
>
> Attachments: OAK-203.patch
>
>
> There are some cases where clients or even the JCR spec expect same name
> siblings to be supported. We should have some mechanism to allow such cases
> to work with no or minimal required changes. Such a mechanism doesn't need be
> fully compliant with the SNS feature as specified by JCR, just good enough to
> to cover the most common use cases.
> My initial thinking on this is that, whichever way we end up implementing
> this, it would be nice if the underlying oak-core and microkernel -level SNS
> nodes simply used the "name[index]" naming pattern with no extra semantics
> associated with it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
