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: Dropping ItemImpl.checkPropertected()
Date Tue, 26 Feb 2013 08:14:14 GMT
-1 from my side. i think it's important to distinguish protected
items that are meant to be filled in by the system or by dedicated API.

if the evaluation is slow we should optimize it.

kind regards

On 2/25/13 2:17 PM, Jukka Zitting wrote:
> Hi,
> While doing some basic benchmarking of transient addNode() and
> setProperty() calls I noticed that almost half of the time taken by
> those methods goes into the checkProtected() calls that looks up the
> relevant item definition and verifies that the item in question is not
> protected.
> We could optimize that check a lot by explicitly keeping track of
> effective node types and item definitions (like what jackrabbit-core
> does), but I'd rather avoid the extra overhead unless we have a really
> compelling reason for why this should be done before save(), since in
> any case we'll be enforcing such rules in the commit hooks.
> Furthermore no existing client code should be broken by such a change
> since there's hardly code out there that explicitly tries to modify
> protected items
> I tried disabling the protection checks and the only TCK test that
> fails is  NodeTest.testPrimaryTypeProtected(). I'd declare that as a
> known issue and rather have the relevant check postponed to save()
> where a validator can take care of it.
> Thoughts on this? Unless anyone has strong objections, I'd suggest we
> simply drop the checkProtected() calls and have the relevant
> constraints enforced during save().
> BR,
> Jukka Zitting

View raw message