[
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803123#comment-13803123
]
angela edited comment on OAK-482 at 10/23/13 6:41 PM:
------------------------------------------------------
thomas suggest another alternative:
h6. variant 3:
instead of having multivalued rep:members properties underneath the member
nodes we might also consider having non-residual single valued properties (e.g.
rep:member). the drawback is that there would be a node for every member
property.
was (Author: anchela):
thomas suggest another alternative: instead of having multivalued rep:members
properties underneath the member nodes we might also consider having
non-residual single valued properties (e.g. rep:member). the drawback is that
there would be a node for every member property.
> 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.
> - the node names in the tree structure would rely on userId being equal
> to the principal name, which is not mandated.
> for a new implementation in oak i see the following variants to provide this
> feature:
> h6. variant 1:
> - 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
> pros:
> - dedicated property index for rep:members property defined by rep:Members
> works out of the box -> performance of membership lookup.
> - fixing SNS definition
> - fixing confusion of uid with principalname
> cons:
> - not backwards compatible out of the box
> - updating membership might not be efficient
> - we need to add backwards compatible behavior when reading and querying
> existing membership information or provide an upgrade path that converts
> 'old' structure to the new one upon repo upgrade
> h6. variant 2:
> - rebuild use same logic as in JR2.x to build tree structure but include
> fixing the principalName/uid issue.
> pros:
> - backwards compatible (no upgrade path required)
> - most probably changing membership of a group was more efficient
> cons:
> - efficient lookup of membership doesn't work (AFAIK the property index is
> limited
> to named properties). thus we probably need to adjust the query/index logic
> such that
> a property index can be created for residual properties defined by the
> rep:Members node type
> - SNS problem not addressed -> might cause failure upon upgrade
--
This message was sent by Atlassian JIRA
(v6.1#6144)
