Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Date: Wed, 21 Mar 2012 17:09:40 +0000 (UTC)
From: "Marcel Reutegger (Commented) (JIRA)" <jira@apache.org>
To: oak-dev@jackrabbit.apache.org
Message-ID: 
 <1856044370.42518.1332349780588.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <2146223278.24937.1331911539195.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (OAK-28) Query implementation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Marcel Reutegger commented on OAK-28:
-------------------------------------

> query string

see also the executeQuery method in the Jackrabbit 2.4 SPI:
http://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/spi/RepositoryService.html#executeQuery%28org.apache.jackrabbit.spi.SessionInfo,%20java.lang.String,%20java.lang.String,%20java.util.Map,%20long,%20long,%20java.util.Map%29

It also passes limit and offset because JCR 2.0 Query has setLimit() and setOffset(). Furthermore it passes a map of bound values, but I'm not sure if that's really necessary. I'd say the oak-jcr client could just as well put the values as literals into the serialized query statement.
                
> 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