-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 angela 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
