[jira] [Comment Edited] (OAK-482) Group members stored in a rep:members tree
[
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827774#comment-13827774
]
Tobias Bocanegra edited comment on OAK-482 at 11/20/13 4:13 PM:
Current Nodetypes:
{noformat}
[rep:Group] rep:Authorizable
+ rep:members (rep:Members) = rep:Members multiple protected VERSION /*
FIXME: SNS definition */
- rep:members (WEAKREFERENCE) protected multiple 'rep:Authorizable'
[rep:Members]
orderable
+ * (rep:Members) = rep:Members protected multiple /* FIXME: SNS definition */
- * (WEAKREFERENCE) protected 'rep:Authorizable' /* FIXME: OAK-482 */
{noformat}
Proposed new Nodetypes:
{noformat}
[rep:Group] rep:Authorizable, rep:Members
+ rep:membersList (rep:MembersList) = rep:MembersList protected VERSION
[rep:MembersList]
+ * (rep:Members) = rep:Members protected COPY
[rep:Members]
- rep:members (WEAKREFERENCE) protected multiple 'rep:Authorizable'
{noformat}
was (Author: tripod):
Removed documentation:
---
h3. Group Membership
With the default configuration Jackrabbit 2.x stores the group members as _weak
references_ in a `rep:members` multi value property in the group node. If the
`groupMembershipSplitSize` configuration parameter is set and valid, the group
memberships are collected in a node structure below `rep:members` instead of
the default multi valued property. Its value determines the maximum number of
member properties until additional intermediate nodes are inserted. Valid
parameter values are integers 4. The node structure is a balanced b-tree
where only the leave nodes carry the actual values in residual properties which
name is the principal name of the member.
**New Behavior**
As of **Oak** the user manager automatically chooses an appropriate storage
structure depending on the number of group members. If the number of members is
low they are store as _weak references_ in a `rep:members` multi value
property. This is similar to Jackrabbit 2.x. If the number of members is high
the user manager will create an intermediate node list to reduce the size of
the multi value properties below a `rep:membersList` node.
h4. Related node types
{noformat}
[rep:Group] rep:Authorizable, rep:Members
+ rep:membersList (rep:MembersList) = rep:MembersList protected VERSION
[rep:MembersList]
+ * (rep:Members) = rep:Members protected COPY
[rep:Members]
- rep:members (WEAKREFERENCE) protected multiple 'rep:Authorizable'
{noformat}
h4. Example Group with few members
*(irrelevant properties excluded)*
{noformat}
{
jcr:primaryType: rep:Group,
rep:principalName: contributor,
rep:members: [
429bbd5b-46a6-3c3d-808b-5fd4219d5c4d,
ca58c408-fe06-357e-953c-2d23ffe1e096,
3ebb1c04-76dd-317e-a9ee-5164182bc390,
d3c827d3-4db2-30cc-9c41-0ed8117dbaff,
f5777a0b-a933-3b4d-9405-613d8bc39cc7,
fdd1547a-b19a-3154-90da-1eae8c2c3504,
65c3084e-abfc-3719-8223-72c6cb9a3d6f
]
}
{noformat}
h4. Example Group with many members
*(irrelevant properties excluded)*
{noformat}
{
jcr:primaryType: rep:Group,
rep:principalName: employees,
rep:membersList: {
jcr:primaryType: rep:MembersList,
0: {
jcr:primaryType: rep:Members,
rep:members: [
429bbd5b-46a6-3c3d-808b-5fd4219d5c4d,
ca58c408-fe06-357e-953c-2d23ffe1e096,
...
]
},
...
341: {
jcr:primaryType: rep:Members,
rep:members: [
fdd1547a-b19a-3154-90da-1eae8c2c3504,
65c3084e-abfc-3719-8223-72c6cb9a3d6f,
...
]
}
}
}
{noformat}
*Note*: The exact threshold value that determines the storage strategy is an
implementation detail and might even vary depending on the underlying
persistence layer.
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
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
[jira] [Comment Edited] (OAK-482) Group members stored in a rep:members tree
[ https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13803123#comment-13803123 ] angela edited comment on OAK-482 at 10/23/13 6:41 PM: -- thomas suggest another alternative: h6. variant 3: instead of having multivalued rep:members properties underneath the member nodes we might also consider having non-residual single valued properties (e.g. rep:member). the drawback is that there would be a node for every member property. apart from that same applies as for variant 2. was (Author: anchela): thomas suggest another alternative: h6. variant 3: instead of having multivalued rep:members properties underneath the member nodes we might also consider having non-residual single valued properties (e.g. rep:member). the drawback is that there would be a node for every member property. 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 was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (OAK-482) Group members stored in a rep:members tree
[ https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13803123#comment-13803123 ] angela edited comment on OAK-482 at 10/23/13 6:41 PM: -- thomas suggest another alternative: h6. variant 3: instead of having multivalued rep:members properties underneath the member nodes we might also consider having non-residual single valued properties (e.g. rep:member). the drawback is that there would be a node for every member property. was (Author: anchela): thomas suggest another alternative: instead of having multivalued rep:members properties underneath the member nodes we might also consider having non-residual single valued properties (e.g. rep:member). the drawback is that there would be a node for every member property. 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 was sent by Atlassian JIRA (v6.1#6144)
