[
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526470#comment-13526470
]
Michael Dürig commented on OAK-482:
-----------------------------------
Do we even need the members tree the same way we had it in JR2? The reason to
split it into multiple levels there was JR2 not supporting large numbers of
direct children of a node. Since this wont be a problem any more with Oak,
couldn't we make the members tree flat? That would be equivalent to specifying
a very large value for {{groupMembershipSplitSize}} in JR2.
If there are still backward compatibility concerns with this, why not make it
flat by default and support the other structure as "deprecated compatibility
mode"?
> Group members stored in a rep:members tree
> ------------------------------------------
>
> Key: OAK-482
> URL: https://issues.apache.org/jira/browse/OAK-482
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core
> Reporter: angela
>
> storing group members in a dedicated rep:members tree is currently not
> yet implemented.
> - jr 2.x node type definition allows SNS which are not supported in oak
> - jr 2.x node type definition stores members in residual properties, which
> up to now doesn't allow to use a specific property index.
> - the jr 2.x implementation is rather cumbersome as it doesn't allow
> to change the configuration later on such that existing groups can
> benefit from the config change.
> for a new implementation in oak i would like to slightly change the
> way group members are stored in a hierarchy:
> - drop SNS
> - change member-property to a multivalue rep:members property in the
> node hierarchy -> same index as for non-tree implementation
> - config change will result in the member-tree to be created also for
> existing groups.
> - even if member-tree option is enabled the members are stored in the
> default mv property and just have a tree structured added if required
> based on the config option.
> - adjust xml import of user content accordingly
> this would required the following additional steps:
> - add backwards compatible behavior when reading and querying
> existing membership information.
> - ev. add commit hook that migrates the 'old' structure to the new one
> upon modification of the group
> - ev. add migration path (depending on how we envision upgrading from
> jr 2.x to oak in general).
--
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
