i am not totally sure if the checkProtection can be delayed until
the save call. the specification states:
"If an item I is declared protected it is repository-controlled.
If I is a node then, through the core write methods of JCR (see
§10.2 Core Write Methods),
• I cannot be removed,
• child nodes of I cannot be added, removed, or reordered,
• properties of I cannot be added or removed,
• the values of existing properties of I cannot be changed,
• the primary node type of I cannot be changed and
• mixin node types cannot be added to or removed from I.
If I is a property then, through the core write methods of JCR (see
§10.2 Core
Write Methods),
• I cannot be removed and
• the value of I cannot be changed.
"
usually the specification explicitly states if a given validation
may be postponed until the save-call which is not the case here.
kind regards
angela
On 2/26/13 11:25 AM, Jukka Zitting wrote:
Hi,
On Tue, Feb 26, 2013 at 11:08 AM, Marcel Reutegger<[email protected]> wrote:
I'd be OK to replace the full-fledged checked in each call with a simple
hardcoded set of well-known protected properties. the full check on
save() would then take care of the rest.
If we do keep the check in the transient operations like addNode and
setProperty, then I think it's best to do the check properly to avoid
weird corner cases (like whether jcr:uuid should be protected in
non-referenceable nt:unstructured nodes). It should be possible to
optimize the checkProtected() method down to microsecond range if we
go that route.
My main point here is whether such optimization is needed in the first
place since these checks are just duplicating effort that in any case
needs to be done during save().
BR,
Jukka Zitting
