[
https://issues.apache.org/jira/browse/OAK-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13589529#comment-13589529
]
Jukka Zitting commented on OAK-660:
-----------------------------------
bq. 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.
I'd simply rely on the cache we already have for the underlying node states. In
other words, instead of pre-fetching the permission information to memory (and
then having to refresh/reload it when needed), we could load it on-demand and
thus automatically see the correct revision and leverage the underlying node
state cache.
> 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
