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 11:11:47 GMT
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

On 2/26/13 11:25 AM, Jukka Zitting wrote:
> Hi,
> On Tue, Feb 26, 2013 at 11:08 AM, Marcel Reutegger<mreutegg@adobe.com>  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

View raw message