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

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

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

angela updated OAK-482:
-----------------------

    Description: 
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



  was:
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).

    
> 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 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