[
https://issues.apache.org/jira/browse/OAK-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234409#comment-13234409
]
Thomas Mueller commented on OAK-28:
-----------------------------------
> Should it take a query string of some intermediate query language?
I think it should take a query string of any of the supported languages, which
are SQL-2 and XPath at the moment.
> Should it take an AST of a query?
I think oak-core should take a query string only. The JQOM implementation in
oak-jcr can create a SQL-2 query string. Creating and parsing a query string is
quite fast, I don't expect performance to be an issue here. (Calculating the
query plan might actually take longer - if we want to speed up things we should
look at caching those and possibly caching query results).
> What about an extension to JQOM as was proposed by Felix?
>From what I heard it's a bit complicated to support as the JQOM classes are
>not easily extensible (this is a problem of the JCR API which can't be easily
>solved). But I don't know the details here yet.
Extending the query language on the other hand is quite simple. As an example,
the current implementation supports "explain select ..." in addition to "select
...".
> avoid code duplications
There is some duplication: the JQOM implementation roughly matches the parse
tree (at the moment). I don't see how this code duplication could be avoided,
unless if we want to make it less modular (use the JCR API within oak-core, or
move the query implementation in oak-jcr). On the other hand, it simplifies
extending the parse tree. I currently don't see it as a big problem. It was a
bit of work to copy the classes, but now it's done.
> Query implementation
> --------------------
>
> Key: OAK-28
> URL: https://issues.apache.org/jira/browse/OAK-28
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Attachments: OakToJcrQueryTreeConverter.java
>
>
> A query engine needs to be implemented.
> This includes a query parser in oak-core (where we don't want to use the JCR
> API), and a query parser in oak-jcr (where the parsed query tree needs to
> implement the JCR API).
> To avoid writing two independent parsers, I suggest to change the parser to
> emit a non-JCR query tree (so the parser can be used in oak-core). There
> needs to be a converter from the non-JCR query tree to a JCR query tree, so
> the same parser can be used in oak-jcr.
> This will still require two independent query tree implementations (about 37
> duplicated classes: 37 classes for oak-core and 37 classes in oak-jcr). Plus
> it requires a tree converter.
> If somebody has a better idea please tell me :-)
> Prototype implementation of the query tree converter. Please note the class
> names are only to for illustration, but I don't know yet a good naming
> convention. Ideas are welcome!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
