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

2013-11-22 Thread Tobias Bocanegra (JIRA) 

[ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13830599#comment-13830599
 ] 

Tobias Bocanegra commented on OAK-482:
--

added minor fix in r1544748:
- rep:memberRefencesList must be OPV=Copy, otherwise the member-versioning 
behavior differs based on storage implementation.
- update membership docu

 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)

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

2013-11-20 Thread angela (JIRA) 

[ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827526#comment-13827526
 ] 

angela commented on OAK-482:


in the docu section it seems that you wanted to redefined the rep:Members node 
type definition.  i would strongly recommend not to do this but keep the 
original node type definitions as they are but just deprecate them.

btw: i find it a bit inconvenient if the docu section is updated before the 
code is modified. this is asking for outdated and wrong documentation because 
once we will produce a final release nobody will have time to carefully verify 
that the docu is updated. i will remove the corresponding section from the 
documentation.

 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 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] [Commented] (OAK-482) Group members stored in a rep:members tree

2013-11-20 Thread Tobias Bocanegra (JIRA) 

[ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827771#comment-13827771
 ] 

Tobias Bocanegra commented on OAK-482:
--

bq. in the docu section it seems that you wanted to redefined the rep:Members 
node type definition. i would strongly recommend not to do this but keep the 
original node type definitions as they are but just deprecate them.

why? those are internal nodetype definitions and are not used by users. the new 
definition is consistent with the new membership implementation approach and 
the content will be converted during a potential upgrade.

bq. btw: i find it a bit inconvenient if the docu section is updated before the 
code is modified. this is asking for outdated and wrong documentation because 
once we will produce a final release nobody will have time to carefully verify 
that the docu is updated. i will remove the corresponding section from the 
documentation.

I disagree. having the docu early allows others to review and rise questions if 
the intended change will impact their applications. but if you feel more 
comfortable, I'll move it to this issue.


 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 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] [Commented] (OAK-482) Group members stored in a rep:members tree

2013-11-20 Thread Tobias Bocanegra (JIRA) 

[ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827774#comment-13827774
 ] 

Tobias Bocanegra commented on OAK-482:
--

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

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

2013-11-20 Thread angela (JIRA) 

[ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827791#comment-13827791
 ] 

angela commented on OAK-482:


regarding node type definitions:

it's a node type definition that has been release and IMO is therefore sort of 
public API.
second we need to be able to migrate jr2 group information into oak and i would 
definitely love to be able to XML import jr2 group information into oak. if we 
have collisions in node type definitions i feel that this will cause troubles. 
third changing node type definitions used to be very troublesome in the past... 
i'd rather want to avoid any kind of issues that may arise here by just not 
reusing existing node type names for something else... but maybe i am too 
cautious :-)

 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 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] [Commented] (OAK-482) Group members stored in a rep:members tree

2013-11-20 Thread angela (JIRA) 

[ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827840#comment-13827840
 ] 

angela commented on OAK-482:


my preference would be rep:MemberReferences.
but if you have the feeling that my concerns wrt to changing rep:Member are 
exaggerate, you can give it a try... as long as we have sufficient test 
coverage.


 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 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] [Commented] (OAK-482) Group members stored in a rep:members tree

2013-11-20 Thread Tobias Bocanegra (JIRA) 

[ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13828362#comment-13828362
 ] 

Tobias Bocanegra commented on OAK-482:
--

New proposed nodetypes:
{noformat}
[rep:Group]  rep:Authorizable, rep:MemberReferences
  + rep:members (rep:Members) = rep:Members multiple protected VERSION /* 
@deprecated since oak 1.0 (remove?) */
  + rep:membersList (rep:MemberReferencesList) = rep:MemberReferencesList 
protected VERSION /* @since oak 1.0 */

/*
 * @deprecated since oak 1.0
 */
[rep:Members]
  orderable
  + * (rep:Members) = rep:Members protected multiple
  - * (WEAKREFERENCE) protected  'rep:Authorizable'

/**
 * @since oak 1.0
 */
[rep:MemberReferences]
  - rep:members (WEAKREFERENCE) protected multiple  'rep:Authorizable'

/**
 * @since oak 1.0
 */
[rep:MemberReferencesList]
  + * (rep:MemberReferences) = rep:MemberReferences protected COPY
{noformat}

 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 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] [Commented] (OAK-482) Group members stored in a rep:members tree

2013-11-15 Thread Tobias Bocanegra (JIRA) 

[ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13824313#comment-13824313
 ] 

Tobias Bocanegra commented on OAK-482:
--

Note:
* with OAK-1137, the references lookup should be fast(er) even for residual 
properties. but if the current query algorithm is used, there will always be an 
iteration over the properties of a node in order to find a membership.
* I would prefer storing many (1000) memberships in a MV property vs. storing 
1000 single value properties in a node if we gain lookup performance by a fixed 
property name index.
* alternatively, we could use the BTree from JR2 but with the UUID instead of 
the userid as key.

Suggest:
* having a flat sequential node list under a rep:members node, filled with 
rep:members mv properties. so variant1 but with a flat structure.

{noformat}
/home/groups/grp1
  /rep:members
/0 [rep:Members]
  - rep:members [, xxx, ... ]  (WeakRef)
/1 [rep:Members]
  - rep:members [, xxx, ... ]  (WeakRef)
   ...
{noformat}


 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 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] [Commented] (OAK-482) Group members stored in a rep:members tree

2013-11-07 Thread angela (JIRA) 

[ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13816174#comment-13816174
 ] 

angela commented on OAK-482:


NOTE: implementing this not only requires filling in the missing functionality 
in the MembershipProvider but also

- UserValidator (see OAK-615)
- UserImporter
and depending on how we implement this, we may also need to adjust the 
- UserQuery which has some specific selectors for group membership.

 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


 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] [Commented] (OAK-482) Group members stored in a rep:members tree

2013-10-23 Thread angela (JIRA) 

[ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13803123#comment-13803123
 ] 

angela commented on OAK-482:


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)

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

2013-10-23 Thread angela (JIRA) 

[ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13803129#comment-13803129
 ] 

angela commented on OAK-482:


[~tri...@apache.org]: assigning to you as discussed.

 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

 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] [Commented] (OAK-482) Group members stored in a rep:members tree

2013-02-21 Thread Thomas Mueller (JIRA) 

[ 
https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583000#comment-13583000
 ] 

Thomas Mueller commented on OAK-482:


Sorry I clicked somewhere by mistake and this assigned this issue to me. I 
assigned it to Angela (I hope that's correct).

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

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