[ 
https://issues.apache.org/jira/browse/OAK-9587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Evgeny Tugarev updated OAK-9587:
--------------------------------
    Description: 
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 
falling back to traverse and failing as it traversing > 100 000 nodes.

And, yes, it's an urgent issue :) 

  was:
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 the high costPerExecution and 
costPerEntry has a negative side effect of the query falling back to traverse 
and fails as it traverses > 100 000 nodes.

And, yes, it's an urgent issue :) 


> 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: oak-search
>    Affects Versions: 1.42.0
>            Reporter: Evgeny Tugarev
>            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 
> falling back to traverse and failing as it traversing > 100 000 nodes.
> And, yes, it's an urgent issue :) 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to