[
https://issues.apache.org/jira/browse/OAK-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876271#comment-13876271
]
Thomas Mueller commented on OAK-1325:
-------------------------------------
I agree, custom functions would make sense. The query engine would ask the
indexes if they understand the function, and if yes the query engine would use
that index. That way, the index implementation would be responsible.
One open question is: how does the query engine process the result of the
index, if the result is not a node. Currently, the query engine assumes the
index returns paths: the interface Cursor is an Iterator of IndexRow, and each
IndexRow has a path (getPath). The query engine tries to load the node at that
path to verify access rights. This doesn't work well for queries that don't
actually return nodes (such as "MoreLikeThis" queries). I see two solutions:
* The index implementation could return a node for such cases (possibly a
hardcoded node such as "/"), and the payload (data that is only stored in the
index but not in the node itself) could be returned as "special" properties via
IndexRow.getValue. In that case, the query would need to be written with that
in mind, for example "select * from [nt:base] where moreLikeThis('xyz')" would
only return the data stored in the node (and not actually the result of
modeLikeThis). The query would need to be written for example as follows:
"select moreLikeThis() from [nt:base] where moreLikeThis('xyz')". The advantage
is: the query engine could perform access right checks.
* The index implementation could return null as the path so that the query
engine knows it's not a node, and the payload via "special" properties, but
this time it could be a (set of) hardcoded property names. That would work
because the query engine would know it's not a node. That way, the query could
in fact be written as "select * from [nt:base] where moreLikeThis('xyz')". The
disadvantage is, the query engine couldn't perform access any right checks.
> 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
>
> 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)
