[ https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Marth updated OAK-482: ------------------------------ Fix Version/s: 0.13 > 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 > Assignee: Tobias Bocanegra > Fix For: 0.13 > > > 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)