[
https://issues.apache.org/jira/browse/OAK-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13578591#comment-13578591
]
angela commented on OAK-626:
----------------------------
> Something like setOrderable() or setOrderableChildren()
yes... looks better.
> Thus, it is perfectly fine for oak-core to have an orderable tree where even
> though it is not mix:orderable.
ok. i can live with that (btw: there is no mix:orderable... it's a flag on the
node type definition)
> Regarding the OAK_CHILD_ORDER I think its presence should indicate
> orderability.
that's an implementation detail, isn't it?
apart from that it's a hidden property which we don't want to expose on the
oak-api for
the security reasons outlined by marcel some time ago (if i remember correctly
at the time
we introduced the orderBefore method).
but that wasn't my question basically... i was just wondering if we care if
the OAK_CHILD_ORDER conflicts with the node type definition. in other words
if it should considered a violation if trees are reordered when the
corresponding
node could not... just for the completeness such that we can make the API
contract unambiguous. if we all agree that we don't tie one thing to the other,
i would state that in the API contract of both methods (setOrderable,
orderBefore).
> Allow for setting orderable child nodes on the parent tree
> ----------------------------------------------------------
>
> Key: OAK-626
> URL: https://issues.apache.org/jira/browse/OAK-626
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: angela
> Attachments: OAK-626.patch
>
>
> currently the only way to enforce orderable child nodes is to call
> Tree#orderBefore. IMHO this doesn't properly reflect the fact that
> the requirement for ordered child nodes is defined by the primary
> node type of the parent rather than by the child nodes.
> i see 2 different ways how we could implement this:
> 1) the tree evaluates it's primary type and sets the OAK_CHILD_ORDER
> property accordingly
> 2) we extend the Tree interface and delegate the responsibility to the
> API caller -> patch attached that also removes the hack on TreeUtil
> in case of 2) we should/could adjust oak-jcr to call this method upon
> adding child nodes or changing the primary type instead of calling a
> fake-reorder that currently asserts that the child order is stable.
> open question regarding 2:
> should oak-core verify if the primary type mandates orderable child
> nodes upon reorder or calling the new method? should it be allowed
> to have the OAK_CHILD_ORDER property if the children are not orderable?
> should calling reorder fail in that case?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
