You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2013/02/28 15:17:12 UTC

[jira] [Comment Edited] (OAK-660) ReadOnlyTree: implement Object#equals and Object#hashCode

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

angela edited comment on OAK-660 at 2/28/13 2:16 PM:
-----------------------------------------------------

i built and had to deal with jr permission eval... i would argue that this is sufficient experience to
know on what needs to be done what can be considered premature optimization and problematic from a
caching point of view.

may i ask you to focus on this issue and the patch. if you object it i will work out another way to
achieve my goals.
                
      was (Author: anchela):
    i built and had to deal with jr permission eval... i would argue that this is sufficient experience to
know on what needs to be done what can be considered premature optimization and problematic from a
caching point of view.
                  
> ReadOnlyTree: implement Object#equals and Object#hashCode
> ---------------------------------------------------------
>
>                 Key: OAK-660
>                 URL: https://issues.apache.org/jira/browse/OAK-660
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: angela
>            Priority: Minor
>         Attachments: OAK-660.patch
>
>
> for OAK-527 i was looking for way to detect changes to the permission store 
> in an efficient and performing way without reloading the complete permissions upon every single call to Root#refresh and Root#rebase.
> in a private discussion with Marcel he pointed out the fact that comparing
> NodeStates that hold the permission information for a given set of principals
> i would most probably do the trick. however this comes with the drawback of
> loosing all hierarchy information when changing the permission provider to work on oak-spi interface instead of using (ReadOnly)Trees, which is a
> bit unfortunate in a hierarchy-aware permission evaluation.
> since one of the  reason for having the ReadOnlyTree implementation IMO is 
> to bring Tree-functionality to a NodeState whose ancestors have been accessed
> before, i would like to suggest to add implementations for #equals and 
> #hashCode to ReadOnlyTree that more or less reflect the those of the underlying NodeState.

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