[jira] [Resolved] (OAK-482) Group members stored in a rep:members tree

["Tobias Bocanegra (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tobias Bocanegra resolved OAK-482.
----------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 0.13)
                   0.12

fixed in r1544743:
- improve user importer to handle new oak member node structure
- add tests to check the import of the new oak member node structure


> 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.12
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> 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)