jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-28) Query implementation
Date Wed, 21 Mar 2012 15:17:44 GMT

    [ 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

        

Mime
View raw message