-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
Hi,
On Tue, Feb 26, 2013 at 10:14 AM, Angela Schreiber anch...@adobe.com
wrote:
-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.
Agreed, but do we need to make this distinction separately during each
Hi,
Large transactions: I think we didn't define this as a strict requirement.
I'm not aware we got into big troubles with Jackrabbit 2.x where this is
not supported. For me, this is still a nice to have. But of course it's
something we should test and try to achieve (and resolve problems if we
Hi,
On Tue, Feb 26, 2013 at 12:04 PM, Thomas Mueller muel...@adobe.com wrote:
Large transactions: I think we didn't define this as a strict requirement.
It's probably not the most important thing for Oak to achieve, but we
did list it as a goal in
On 26/feb/2013, at 11:12, Jukka Zitting wrote:
Hi,
On Tue, Feb 26, 2013 at 12:04 PM, Thomas Mueller muel...@adobe.com wrote:
Large transactions: I think we didn't define this as a strict requirement.
It's probably not the most important thing for Oak to achieve, but we
did list it as a
Hi,
On Tue, Feb 26, 2013 at 11:08 AM, Marcel Reutegger mreut...@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
I didn't analyze the results, but could the problem be orderable child
nodes? Currently, oak-core stores a property :childOrder.
no, the problem is how oak-core detects changes between two node
state revisions. for a node with many child nodes in two revisions, oak-core
currently loads all
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
Hi,
On Tue, Feb 26, 2013 at 4:26 PM, Travis-CI notificati...@travis-ci.org wrote:
Status: Broken
Oops, looks like the TCK (or the way we set it up) has quite a few
expectations on nt:unstructured. I reverted the rep:root change in
revision 1450193.
BR,
Jukka Zitting
