jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Dropping ItemImpl.checkPropertected()
Date Mon, 25 Feb 2013 13:17:04 GMT

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

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().


Jukka Zitting

View raw message