[
https://issues.apache.org/jira/browse/OAK-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13589591#comment-13589591
]
angela commented on OAK-660:
----------------------------
what jukka is suggesting above is already implemented and visible to
everyone... so, instead of
just arguing from the top your head what might or might not be then intent you
could just take a
quick look before pretending the setup was wrong altogether... this is a
re-occurring pattern
and after writing a long explanation you keep saying "ahhhhh didn't know
that... i thought it was
the other way round".
> Equality does not take the name of the tree into consideration. This might be
> intended but is surely not expected by clients.
i had that in the initial draft but at the end wasn't sure whether it's really
needed. :-)
if it makes your more comfortable with the patch, i can add it. otherwise i
will go and look
for another solution and leave the ReadOnlyTree untouched by basically creating
my own hierarchy-aware
nodestate-tree. that would also allow me to deal with the getPath() in an
efficient manner... no problem whatsoever.
> 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
