[
https://issues.apache.org/jira/browse/OAK-6579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16166534#comment-16166534
]
Thomas Mueller commented on OAK-6579:
-------------------------------------
The patch looks good to me!
There is some risk of regression, I wonder if it can be reduced. One option
would be to use a different index type, for example rename the old one to
"counterOld", and the new one "counter", and then in case of problems use
"counterOld" (so that in case of problems, one only has to switch to
"counterOld", and doesn't have to wait for a hotfix). Maybe not worth it. What
do you think?
It's a bit sad that the path needs to be stored, but I'm not sure if this can
be avoided. I wonder the result of "mountInfoProvider.getMountByPath" could be
re-used in most cases, so that the path is not needed (or can be constructed
only when needed, from the name plus the parent path, recursively).
> 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.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)
