jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: svn commit: r1465664 - /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/core/SecureNodeState.java
Date Tue, 09 Apr 2013 14:49:59 GMT
hi jukka

> On Tue, Apr 9, 2013 at 12:45 PM, Angela Schreiber<anchela@adobe.com>  wrote:
>> i am not convinced this is a wise move. as i keep stating we used
>> to have short lived sessions that rather perform random access to the
>> repository instead of reading the complete ancestor tree. calculating
>> the readstatus for all ancestors may therefore not be required. since
>> currently the method is still an open TODO, i would prefer to retrieve
>> the reastatus on demand.
> How about we change the order of the checks, so that the readStatus is
> pre-loaded only when child.getChildNodeCount() == 0? That way we could
> avoid unnecessarily evaluating permissions at ancestor nodes, but
> still avoid the cost of the SecureNodeState wrapper for most leaf
> nodes.

sure, we can try that... in general i would prefer to get a better
picture on the overall impact first before starting to optimize
things and make the code complicated.

for example: moving down the evaluation on the NodeState level
now has an impact on how we deal with the TreeLocation [0]: it's
no longer possible to access an Tree that has a inaccessible
parent node, which basically was the whole story about the TreeLocation!
i am not sure if this is solely related to the security move or
whether the most recent changes to the TreeLocation API is related
as well...

anyway. the point here is that i would prefer to get it to work
first and optimize once we know that it really works.

kind regards

[0] https://issues.apache.org/jira/browse/OAK-766

>> thanks... i will take over and add fixes where needed.
> OK, cool.
> BR,
> Jukka Zitting

View raw message