storing group members in a dedicated rep:members tree is currently not
- 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
- 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
- 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
- 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
- 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
- rebuild use same logic as in JR2.x to build tree structure but include
fixing the principalName/uid issue.
- backwards compatible (no upgrade path required)
- most probably changing membership of a group was more efficient
- 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