You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Thomas Mueller (Jira)" <ji...@apache.org> on 2021/10/15 09:18:00 UTC
[jira] [Commented] (OAK-9587) Add an attribute to enforce a strict
index tag check
[ https://issues.apache.org/jira/browse/OAK-9587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17429199#comment-17429199 ]
Thomas Mueller commented on OAK-9587:
-------------------------------------
I merged the PR in https://github.com/apache/jackrabbit-oak/commit/d73ec45938e3321b90d2bc2eaa83287307c0a7fc
2021-10-15
> Add an attribute to enforce a strict index tag check
> ----------------------------------------------------
>
> Key: OAK-9587
> URL: https://issues.apache.org/jira/browse/OAK-9587
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core, lucene, oak-search
> Affects Versions: 1.40.0
> Reporter: Evgeny Tugarev
> Assignee: Mohit Kataria
> Priority: Major
>
> JCR Query which does not specify an INDEX() tag may eventually pick up the tagged index.
> This is not an error, however this behaviour is not always desirable when a tagged index must only be used by a specific query which explicitly specify an index tag and be transparent to other queries which does not specify it.
> If I understand correctly the check is done [here|https://github.com/apache/jackrabbit-oak/blob/db55659c08dff47e9c28eef03f1a5628af13d8b2/oak-search/src/main/java/org/apache/jackrabbit/oak/plugins/index/search/spi/query/FulltextIndexPlanner.java#L412]
> I propose to add a boolean parameter (strictTagCheck or sth similar) which enforces a strict check for the index tag - the idea is to mark such index as wrong in case query does not specify the index tag and an index definition contains a tag. I think this change is also a backward compatible as does not change the existing behaviour, but adds a new one.
> N.B. Currently a workaround applied to set a high costPerExecution and costPerEntry in index definition has a negative side effect for the query to fall back to traverse and fail after it reads 100 000 nodes.
> And, yes, it's an urgent issue :)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)