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