[jira] [Comment Edited] (OAK-1325) Support native pass-through queries (e.g. Lucene)

["Tommaso Teofili (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13910472#comment-13910472 ] 

Tommaso Teofili edited comment on OAK-1325 at 2/24/14 4:50 PM:
---------------------------------------------------------------

bq. I know we want to support both Lucene and Solr, but I thought both use Lucene internally - so couldn't be the query the same for Solr and Lucene? 

you could run Lucene native query language in Solr but its default is a bit different (see https://wiki.apache.org/solr/SolrQuerySyntax#Differences_From_Lucene_Query_Parser)

bq. So, for example, "native('lucene')" for both?

it could be that Solr handles both native('lucene') and native('solr') as it's actually able to parse both query syntaxes

bq. Or is there a case where somebody would use both a Lucene index and a Solr index at the same time?

It could be, but I don't have a specific scenario in mind.

bq. what about using a syntax that is not at the same time a legal node/property name (a non-ambiguous syntax). For example "select [jcr:path] from [nt:base] where native('solr') = 'name:(Hello OR World)'. The disadvantage is, we need to extend the SQL-2 parser to support the keyword "native"

yes that was the first attempt I made to implement this feature, however I thought changing the SQL-2 syntax was not a good idea as it seemed a bit too intrusive. However if native('$indexname') is a legal property name then I think your suggestion sounds better to avoid very unlikely but still possible corner cases.

One other thing to take care of is the cost evaluation: the ability to execute a native query should have a high impact on the cost of a query so that the engines that are not able to execute that don't get picked up.


was (Author: teofili):
bq. I know we want to support both Lucene and Solr, but I thought both use Lucene internally - so couldn't be the query the same for Solr and Lucene? 

you could run Lucene native query language in Solr but its default is a bit different (see https://wiki.apache.org/solr/SolrQuerySyntax#Differences_From_Lucene_Query_Parser)

bq. So, for example, "native('lucene')" for both?

it could be that Solr handles both native('lucene') and native('solr')

bq. Or is there a case where somebody would use both a Lucene index and a Solr index at the same time?

It could be, but I don't have a specific scenario in mind.

bq. what about using a syntax that is not at the same time a legal node/property name (a non-ambiguous syntax). For example "select [jcr:path] from [nt:base] where native('solr') = 'name:(Hello OR World)'. The disadvantage is, we need to extend the SQL-2 parser to support the keyword "native"

yes that was the first attempt I made to implement this feature, however I thought changing the SQL-2 syntax was not a good idea as it seemed a bit too intrusive. However if native('$indexname') is a legal property name then I think your suggestion sounds better to avoid very unlikely but still possible corner cases.

One other thing to take care of is the cost evaluation: the ability to execute a native query should have a high impact on the cost of a query so that the engines that are not able to execute that don't get picked up.

> Support native pass-through queries (e.g. Lucene)
> -------------------------------------------------
>
>                 Key: OAK-1325
>                 URL: https://issues.apache.org/jira/browse/OAK-1325
>             Project: Jackrabbit Oak
>          Issue Type: New Feature
>          Components: oak-lucene, oak-solr, query
>            Reporter: Thomas Mueller
>         Attachments: OAK-1325.patch
>
>
> The query engine currently supports XPath and SQL-2 queries as documented by the JCR 2.0 specification. Some queries require syntax that goes beyond the JCR 2.0 spec, even thought the feature is supported by the query index. One example is "MoreLikeThis" in OAK-1286.
> We would like an extension point so that a user of Oak can use the feature of the query index. There are multiple options:
> * Use a separate, custom query language (not XPath or SQL-2)
> * Extend the XPath and/or SQL-2 syntax similar to "rep:excerpt()"



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)