[
https://issues.apache.org/jira/browse/OAK-6579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16167478#comment-16167478
]
Tomek Rękawek edited comment on OAK-6579 at 9/15/17 7:50 AM:
-------------------------------------------------------------
[~tmueller], thanks for the quick review :)
Agreed on the path field. I've optimized this a bit, now the path is build
recursively, but it's required only for the first few levels. For example, if
we have /apps & /libs mounts, then the getPath() will be only called for the
root and its direct children. Later on the mountCanChange will be set to false
and the path won't be needed at all. New patch: [^OAK-6579-2.patch]
I was thinking about the counter and counterOld idea - I think it'd be more
useful if the new implementation changed the indexing data structure / format.
However, without the mount info provider configured, it'll store the data
exactly in the same way as without the patch. I'm not sure if this redundancy
(and 2x as much code to maintain) is desirable - especially that the changes
are also present in the NodeCounter. We still have time before the 1.8 release,
so hopefully potential problems will be discovered before that. FWIW I'm
constantly testing the mount-enabled code in the Sling-based products.
was (Author: tomek.rekawek):
[~tmueller], thanks for the quick review :)
Agreed on the path field. I've optimized this a bit, now the path is build
recursively, but it's required only for the first few levels. For example, if
we have /apps & /libs mounts, then the getPath() will be only called for the
root and its direct children. Later on the mountCanChange will be set to false
and the path won't be needed at all.
I was thinking about the counter and counterOld idea - I think it'd be more
useful if the new implementation changed the indexing data structure / format.
However, without the mount info provider configured, it'll store the data
exactly in the same way as without the patch. I'm not sure if this redundancy
(and 2x as much code to maintain) is desirable - especially that the changes
are also present in the NodeCounter. We still have time before the 1.8 release,
so hopefully potential problems will be discovered before that. FWIW I'm
constantly testing the mount-enabled code in the Sling-based products.
> Define how the counter index works in a composite setup
> -------------------------------------------------------
>
> Key: OAK-6579
> URL: https://issues.apache.org/jira/browse/OAK-6579
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: composite, indexing
> Reporter: Robert Munteanu
> Assignee: Tomek Rękawek
> Fix For: 1.8, 1.7.8
>
> Attachments: OAK-6579-2.patch, OAK-6579.patch
>
>
> We need to see if this index can or should be adjusted to work in a composite
> environment.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
