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 2016/11/10 10:25:59 UTC

[jira] [Assigned] (OAK-4080) Fulltext queries: compatibility for "contains" with special characters

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

Thomas Mueller reassigned OAK-4080:
-----------------------------------

    Assignee: Thomas Mueller

> 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)