[
https://issues.apache.org/jira/browse/OAK-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15231652#comment-15231652
]
Chetan Mehrotra edited comment on OAK-4170 at 4/8/16 5:29 AM:
--------------------------------------------------------------
Added the ignored testcase in 1738211. Did a check in LucenePropertyIndex about
impact of this issue and it appears that it does not causes issue with end
result. Reason being that evaluate logic does not {{enforcePropertyExistence}}
if its a relative property (though it should be safe to use relativeProperty as
argument)
{code}
@Override
public boolean evaluate() {
// disable evaluation if a fulltext index is used,
// to avoid running out of memory if the node is large,
// and because we might not implement all features
// such as index aggregation
if (selector.getIndex() instanceof FulltextQueryIndex) {
// first verify if a property level condition exists and if that
// condition checks out, this takes out some extra rows from the
index
// aggregation bits
if (relativePath == null && propertyName != null) {
return enforcePropertyExistence(propertyName, selector);
}
return true;
}
{code}
[~tmueller] Can you have a look? I see 2 options
# Fix the code and pass correct property restriction
# OR do away with this check altogether. These "synthetic" restriction are
treated like normal restriction at index level which then results in addition
query constraints passed for property not null which adds some overhead at
index level (we need to create an unnecessary property index for such
properties). So either mark such "synthetic" restriction in a special way such
that indexes can ignore them or we just do away with them altogether as I do
not see much benefit here
FWIW I got this issue while trying out various queries at [1] where due to this
issue extra garbage property index entries gets created
[1] http://oakutils.appspot.com/generate/index
was (Author: chetanm):
Added the ignored testcase in 1738211. Did a check in LucenePropertyIndex about
impact of this issue and it appears that it does not causes issue with end
result. Reason being that evaluate logic does not {{enforcePropertyExistence}}
if its a relative property (though it should be safe to use relativeProperty as
argument)
{code}
@Override
public boolean evaluate() {
// disable evaluation if a fulltext index is used,
// to avoid running out of memory if the node is large,
// and because we might not implement all features
// such as index aggregation
if (selector.getIndex() instanceof FulltextQueryIndex) {
// first verify if a property level condition exists and if that
// condition checks out, this takes out some extra rows from the
index
// aggregation bits
if (relativePath == null && propertyName != null) {
return enforcePropertyExistence(propertyName, selector);
}
return true;
}
{code}
[~tmueller] Can you have a look? I see 2 options
# Fix the code and pass correct property restriction
# OR do away with this check altogether. These "synthetic" restriction are
treated like normal restriction at index level which then results in addition
query constraints passed for property not null which adds some overhead at
index level. So either mark such "synthetic" restriction in a special way such
that indexes can ignore them or we just do away with them altogether as I do
not see much benefit here
FWIW I got this issue while trying out various queries at [1] where due to this
issue extra garbage property index entries gets created
[1] http://oakutils.appspot.com/generate/index
> QueryEngine adding invalid property restriction for fulltext query
> ------------------------------------------------------------------
>
> Key: OAK-4170
> URL: https://issues.apache.org/jira/browse/OAK-4170
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
> Reporter: Chetan Mehrotra
> Assignee: Thomas Mueller
> Priority: Minor
> Fix For: 1.6, 1.5.1
>
> Attachments: OAK-4170-v1.patch
>
>
> QueryEngine inserts a property restriction of "is not null" for any property
> used in fulltext constraint. For e.g. for query
> {noformat}
> select * from [nt:unstructured] where
> CONTAINS([jcr:content/metadata/comment], 'december')
> {noformat}
> A property restriction would be added for {{jcr:content/metadata/comment}}.
> However currently due to bug in {{FulltextSearchImpl}} [1] the property name
> generated is {{comment/jcr:content/metadata}}.
> {code}
> @Override
> public void restrict(FilterImpl f) {
> if (propertyName != null) {
> if (f.getSelector().equals(selector)) {
> String p = propertyName;
> if (relativePath != null) {
> p = PathUtils.concat(p, relativePath);
> }
> p = normalizePropertyName(p);
> restrictPropertyOnFilter(p, f);
> }
> }
>
> f.restrictFulltextCondition(fullTextSearchExpression.currentValue().getValue(Type.STRING));
> }
> {code}
> This happens because {{relativePath}} is passed as second param to
> {{PathUtils.concat}}. It should be first param
> [1]
> https://github.com/apache/jackrabbit-oak/blob/1.4/oak-core/src/main/java/org/apache/jackrabbit/oak/query/ast/FullTextSearchImpl.java#L275-L286
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
