[ 
https://issues.apache.org/jira/browse/OAK-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15128068#comment-15128068
 ] 

angela edited comment on OAK-3933 at 3/3/16 3:56 PM:
-----------------------------------------------------

Below are a few initial ideas for {{isMember}} and {{isDeclaredMember}}:

1) Avoid having to read all child nodes to check declared membership

Assuming an alphanumeric ID structure, this could be achieved my modifying the 
structure like that:
- as before, start with a single node
- when a new member needs to be inserted and the candidate node is already full 
(has 1000 entries), create a new child node named after the first character of 
the authorizable ID
- when this "level 1" member is full, start using "level 2" members and so on

(assuming the ID structure is suitable for that, otherwise a different hash 
could be used)
To check for membership, we wouldn't need to read *all* child nodes, but only 
those where the node name is a prefix match of the ID.

2) Avoid having to instantiate authorizables for declared membership checks
- put limited type information into the stored IDs, such as "u" and "g" 
prefixes; that way the code could identify authorizables that are users and 
avoid having to instantiate them
(this assumes that an ID that refers to a user will never refer to a group in 
the future)

Another issue is that {{Group}} doesn't expose {{isDeclaredMember()}} which in 
many cases would be faster than {{isMember()}}.


was (Author: reschke):
Another issue is that {{Group}} doesn't expose {{isDeclaredMember()}} which in 
many cases would be faster than {{isMember()}}.

> potential improvements to membership management
> -----------------------------------------------
>
>                 Key: OAK-3933
>                 URL: https://issues.apache.org/jira/browse/OAK-3933
>             Project: Jackrabbit Oak
>          Issue Type: Epic
>          Components: core
>            Reporter: Julian Reschke
>            Assignee: angela
>
> Affected methods are
> - Group.isMember(Authorizable)
> - Group.isDeclaredMember(Authorizable)
> - Group.addMember(Authorizable)
> - Group.addMembers(String...)
> Below are a few initial ideas for {{isMember}} and {{isDeclaredMember}}:
> 1) Avoid having to read all child nodes to check declared membership
> Assuming an alphanumeric ID structure, this could be achieved my modifying 
> the structure like that:
> - as before, start with a single node
> - when a new member needs to be inserted and the candidate node is already 
> full (has 1000 entries), create a new child node named after the first 
> character of the authorizable ID
> - when this "level 1" member is full, start using "level 2" members and so on
> (assuming the ID structure is suitable for that, otherwise a different hash 
> could be used)
> To check for membership, we wouldn't need to read *all* child nodes, but only 
> those where the node name is a prefix match of the ID.
> 2) Avoid having to instantiate authorizables for declared membership checks
> - put limited type information into the stored IDs, such as "u" and "g" 
> prefixes; that way the code could identify authorizables that are users and 
> avoid having to instantiate them
> (this assumes that an ID that refers to a user will never refer to a group in 
> the future)
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to