[jira] [Updated] (OAK-203) Basic same name sibling support

["Michael Dürig (JIRA)" <ji...@apache.org>]

     [ 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)