I realized now that I logged an issue for this recently OAK-5511 which
mentioned similar approach. So lets move this discussion there
Chetan Mehrotra
On Thu, Feb 23, 2017 at 7:06 PM, Thomas Mueller wrote:
> Hi,
>
>>I like Marcel proposal for "enforcing" use of mixin on parent node to
>>indicate
Hi,
>I like Marcel proposal for "enforcing" use of mixin on parent node to
>indicate that it can have a child node of 'oak:index'. So we can
>leverage mxin 'mix:indexable' (OAK-3725) to mark such parent nodes
>(like root) and IndexUpdate would only look for 'oak:index' node if
>current node has th
I like Marcel proposal for "enforcing" use of mixin on parent node to
indicate that it can have a child node of 'oak:index'. So we can
leverage mxin 'mix:indexable' (OAK-3725) to mark such parent nodes
(like root) and IndexUpdate would only look for 'oak:index' node if
current node has that mixin.
hi
yes that mixin exists. but the CugValidatorProvider is performs additional
validation and doesn't allow for usage of the reserved names if the mixin
is not there... so we cannot limit the evaluation to nodes that have the
mixin type set (or inherited through super-type).
see http://jackrabbit.a
On Wed, Feb 22, 2017 at 8:21 PM, Davide Giannella wrote:
> Did you mean for ALL the nodes, or only specific nodes?
>
> Any way you're suggesting something like the following flow:
>
> 1) user call nodebuilder.child(":index")
> 2) lookup in hidden property
> 3) if not there, leverage the existing c
Hi,
For "oak:index" of type oak:QueryIndexDefinition, what about a hidden
property ":hasOakIndex" = true. That would be
NodeBuilder.hasProperty(":hasOakIndex").
Regards,
Thomas
On 22/02/17 12:57, "Chetan Mehrotra" wrote:
>We have some CommitEditors in Oak which look for specific child node
>u
On 22/02/2017 11:57, Chetan Mehrotra wrote:
> One possible approach is to mark the parent with a specific hidden
> property which has such a node upon addition. This would avoid the
> negative lookup in case of updates
Did you mean for ALL the nodes, or only specific nodes?
Any way you're suggest
Hi,
On 22/02/17 12:57, Chetan Mehrotra wrote:
One possible approach is to mark the parent with a specific hidden
property which has such a node upon addition. This would avoid the
negative lookup in case of updates
Alternatively we could also mark the parent node with a mixin. This
would be s
We have some CommitEditors in Oak which look for specific child node
upon each commit like 'oak:index' and 'rep:cugPolicy'
In most cases such child node does not exist and this leads to extra
remote calls in case of DocumentNodeStore to determine if child with
such a name exist or not. In case of
