[
https://issues.apache.org/jira/browse/OAK-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15656471#comment-15656471
]
Tommaso Teofili commented on OAK-4080:
--------------------------------------
I think it'd be useful to have the full stack trace as to see what's going
wrong at the Lucene side, I think this may be depending on the {{Analyzers}} we
use and / or if a field is analyzed or not. Other than that, depending on the
query parser used, special characters that are part of the Lucene query syntax
may have to be
[escaped|https://lucene.apache.org/core/4_0_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#Escaping_Special_Characters].
> Fulltext queries: compatibility for "contains" with special characters
> ----------------------------------------------------------------------
>
> Key: OAK-4080
> URL: https://issues.apache.org/jira/browse/OAK-4080
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: query
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Fix For: 1.8
>
>
> Currently, "jcr:contains" with special characters don't work the same when
> using a Lucene fulltext index compatVersion 2 compared to using compatVersion
> 1 or Jackrabbit 2.x.
> This needs to be documented. Also, it might make sense to provide a
> compatibility flag, so that behavior is the same as with the old versions, at
> least as much as possible, even thought new features would not be supported.
> The one example I know is using "\*" as in:
> {noformat}
> SELECT * FROM [nt:base] AS c WHERE CONTAINS(c.[test], 'athxv:!*')
> {noformat}
> With compatVersion 2, the "\*" needs to be escape as follows, in order to
> match properties with exactly this text:
> {noformat}
> SELECT * FROM [nt:base] AS c WHERE CONTAINS(c.[test], 'athxv:!\*')
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
