jackrabbit-oak-dev mailing list archives

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

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

Jukka Zitting commented on OAK-28:
----------------------------------

bq. ... limit and offset ...

Either add those as explicit parameters or allow them to be passed as a part of the query
string. I think it would be useful to in any case support the latter option, so perhaps that's
all we need?

bq. ... bound values ...

Agreed that those are best serialized along with the query itself. We can add support for
value bindings later on if there's a convincing use case for it.

bq. Why do we need to implement a query parser in the jcr bindings module then?

We don't.
                
> 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