[
https://issues.apache.org/jira/browse/OAK-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023998#comment-16023998
]
Vikas Saurabh edited comment on OAK-5970 at 5/25/17 1:25 AM:
-------------------------------------------------------------
[~chetanm], I think unifying in/excludes after merging all paths from all
indices might not be correct. e.g.
* Idx1 has include=\[/var/a]
* Idx2 has exclude=\[/var]
then by the time we unify, it'd get include=\[/var/a] and exlude=\[/var]..
unify would remove /var/a from includes (as exclude would get priority). I
think a hacky way could be to have something like:
{noformat}
for def in index-defs:
do
unify(def.includes, def.excludes)
global.includes.addAll(def.includes)
global.excludes.addAll(def.excludes)
done
unify(global.excludes, global.includes) //Note, inverted order of include and
exclude...
{noformat}
I haven't thought this through - but my gut logic is that global merge requires
include to be prioritized over exclude - so, the inverted order might work.
[~tmueller], thoughts?
was (Author: catholicon):
[~chetanm], I think unifying in/excludes after merging all paths from all
indices might not be correct. e.g.
* Idx1 has include=\[/var/a]
* Idx2 has exclude=\[/var]
then by the time we unify, it'd get include=\[/var/a] and exlude=\[/var]..
unify would remove /var/a from includes (as exclude would get priority). I
think a hacky way could be to have something like:
{nofromat}
for def in index-defs:
do
unify(def.includes, def.excludes)
global.includes.addAll(def.includes)
global.excludes.addAll(def.excludes)
done
unify(global.excludes, global.includes) //Note, inverted order of include and
exclude...
{noformat}
I haven't thought this through - but my gut logic is that global merge requires
include to be prioritized over exclude - so, the inverted order might work.
[~tmueller], thoughts?
> (Re-)Indexing: estimate progress / ETA
> --------------------------------------
>
> Key: OAK-5970
> URL: https://issues.apache.org/jira/browse/OAK-5970
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing
> Reporter: Thomas Mueller
> Assignee: Chetan Mehrotra
> Fix For: 1.8
>
>
> Reindexing can take a long time, so it would be good if we can estimate where
> we are at (for example in percent of the relevant number of nodes). It might
> also be possible to estimate when indexing will be done, and the current path.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
