[
https://issues.apache.org/jira/browse/OAK-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13589548#comment-13589548
]
Jukka Zitting commented on OAK-660:
-----------------------------------
I see what you mean, but have you benchmarked that? Ultimately a simple
getProperty() or getChild() call shouldn't be notably more expensive than a
lookup in a hash map. And if the content structure is ill suited for the task
at hand, it's possible to use a hook to maintain a hidden, access-optimized
version of that content.
The case here is similar to the pattern we see often with JCR clients where
they end up keeping in-memory caches of various parts of the content tree, and
then have to use observation or other means to figure out when to reload or
refresh that information. With Oak it should be possible to make that pattern
obsolete, and instead rely to simply reading the required information directly
from the repository.
> 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
