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