Define query API
----------------
Key: OAK-34
URL: https://issues.apache.org/jira/browse/OAK-34
Project: Jackrabbit Oak
Issue Type: New Feature
Components: core
Reporter: Michael Dürig
Define a oak-core API for handling queries. How do we handle name space mappings, limit and size. See OAK-28
--
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
[ https://issues.apache.org/jira/browse/OAK-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245277#comment-13245277 ]
Thomas Mueller commented on OAK-34:
-----------------------------------
> drop the XPATH and SQL2 constants. They should instead be defined only in the specific query parser components that implement these languages.
Yes, they are specific to the given service provider. Maybe we could re-use the languages constants defined in the JCR API internally. But they don't need to be in the public API.
> Do we need getBindVariableNames()
Yes, unfortunately... for javax.jcr.query.Query.getBindVariableNames(). I guess the only application that needs it is a generic JCR tool. JDBC has a similar mechanism, some databases still don't support it even today I believe, as very few applications actually use it (java.sql.ParameterMetaData).
> Iterable instead of an Iterator
You are the second person to request it... The interface "Result" could extend extends Iterable<ResultRow>.
> We'll probably need a getSize()
Right. I think more methods will be required as well. What I have so far is the bare minimum to run the minimal test case.
> Should it be possible for a column to be multi-valued?
I believe that's not supported in the JCR API, so I don't think it's required currently.
> More generally, would it be useful to define result sets as a sequence of JSON- or tree-like
> objects instead of using the more specific row abstraction?
Yes that's possible. If we do, we would need to specify the exact mappings.
> Define query API
> ----------------
>
> Key: OAK-34
> URL: https://issues.apache.org/jira/browse/OAK-34
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Michael Dürig
> Labels: query
>
> Define a oak-core API for handling queries. How do we handle name space mappings, value bindings, limit, offset, access rights. See OAK-28
--
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
[ https://issues.apache.org/jira/browse/OAK-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245263#comment-13245263 ]
Jukka Zitting commented on OAK-34:
----------------------------------
Great stuff, thanks for pushing ahead on this! Comments:
* I'd drop the XPATH and SQL2 constants. They should instead be defined only in the specific query parser components that implement these languages.
* Do we need getBindVariableNames()? If not, I'd just allow the client to pass whatever bindings in the executeQuery() call.
* Instead of "Result" I'd use "Hits" or something similar to maintain a clear distinction from the JCR API. But that's a minor detail.
* It would be more convenient to return an Iterable instead of an Iterator from getRows()
* We'll probably need a getSize() method to accompany getRows()
* Should it be possible for a column to be multi-valued?
* More generally, would it be useful to define result sets as a sequence of JSON- or tree-like objects instead of using the more specific row abstraction? That would make it easy for us to extend the query model later on and would allow us to reuse existing tools (JSON serialization, etc.) designed for working with tree structures.
> Define query API
> ----------------
>
> Key: OAK-34
> URL: https://issues.apache.org/jira/browse/OAK-34
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Michael Dürig
> Labels: query
>
> Define a oak-core API for handling queries. How do we handle name space mappings, value bindings, limit, offset, access rights. See OAK-28
--
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
[ https://issues.apache.org/jira/browse/OAK-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245164#comment-13245164 ]
Thomas Mueller commented on OAK-34:
-----------------------------------
> Currently the query needs to be parsed twice.
A query only needs to be parsed twice if the method JCR API method Query.getBindVariableNames() is used. I guess normally this method isn't used, as the application already knows the bind variable names.
> The prepare() method would return a pre-parsed query
That's possible, but it would add another interface (Query) which isn't really necessary most of the time. Also, it wouldn't be necessary to avoid parsing queries twice (if this is what you are worried about). Instead of passing the parsed query to oak-jcr, the query engine in oak-core could keep a query cache. That would also speed up executing repeated queries.
> clients could build queries for their own languages
Currently, the query parsers are within oak-core. If additional query parsers are required, then I think oak-core is the place where they should be registered. I would like to avoid exposing the abstract syntax tree to oak-jcr.
> QueryResult which has an inner interface called Row
Sounds good to me, I will change it.
> Result.getRows() should probably return an Iterable
I also thought about that, but I would like to keep it until we have a good use case for Iterable.
> Maybe Result.getRows() should allow for specifying offset and limit.
Some optimizations might require to know the offset and limit before executing the query (the easiest optimization is using a limit of 0), therefore I would like to specify the offset and limit right when executing the query.
> Define query API
> ----------------
>
> Key: OAK-34
> URL: https://issues.apache.org/jira/browse/OAK-34
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Michael Dürig
> Labels: query
>
> Define a oak-core API for handling queries. How do we handle name space mappings, value bindings, limit, offset, access rights. See OAK-28
--
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
[ https://issues.apache.org/jira/browse/OAK-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245165#comment-13245165 ]
Thomas Mueller commented on OAK-34:
-----------------------------------
> QueryResult
I just saw that would result in a naming collision with javax.jcr.query.QueryResult... Other names already used within javax.jcr.query are Row and Query by the way.
What about making Result and ResultRow inner interfaces of the QueryEngine instead?
> Define query API
> ----------------
>
> Key: OAK-34
> URL: https://issues.apache.org/jira/browse/OAK-34
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Michael Dürig
> Labels: query
>
> Define a oak-core API for handling queries. How do we handle name space mappings, value bindings, limit, offset, access rights. See OAK-28
--
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
[ https://issues.apache.org/jira/browse/OAK-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245315#comment-13245315 ]
Thomas Mueller commented on OAK-34:
-----------------------------------
I have a small generics problem. I'm trying to make Result iterable, but how should the signature look like? The following doesn't compile because "?" seems to be not allowed there:
public interface Result
extends Iterable<? extends ResultRow> // <<== doesn't work
{
...
Iterator<? extends ResultRow> iterator();
}
Without the "extends Iterable" it would compile.
> Define query API
> ----------------
>
> Key: OAK-34
> URL: https://issues.apache.org/jira/browse/OAK-34
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Michael Dürig
> Labels: query
>
> Define a oak-core API for handling queries. How do we handle name space mappings, value bindings, limit, offset, access rights. See OAK-28
--
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
[ https://issues.apache.org/jira/browse/OAK-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Mueller updated OAK-34:
------------------------------
Description: Define a oak-core API for handling queries. How do we handle name space mappings, value bindings, limit, offset, access rights. See OAK-28 (was: Define a oak-core API for handling queries. How do we handle name space mappings, limit and size. See OAK-28)
> Define query API
> ----------------
>
> Key: OAK-34
> URL: https://issues.apache.org/jira/browse/OAK-34
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Michael Dürig
> Labels: query
>
> Define a oak-core API for handling queries. How do we handle name space mappings, value bindings, limit, offset, access rights. See OAK-28
--
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
[ https://issues.apache.org/jira/browse/OAK-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245134#comment-13245134 ]
Michael Dürig commented on OAK-34:
----------------------------------
* Currently the query needs to be parsed twice. Once in QueryEngine.getBindVariableNames() and a second time in QueryEngine.executeQuery(). Why not change this into QueryEngine.prepare() and QueryEngine.execute()? The prepare() method would return a pre-parsed query and provide means to bind the free variables. The execute() method would simple execute such a query. If we factor the pre-parsed query into an interface, we would at the same time get extensibility: clients could build queries for their own languages and pass them directly to the execute() method without going through prepare().
* Naming: Result and ResultRow should have more specific names. I propose QueryResult which has an inner interface called Row.
* Result.getRows() should probably return an Iterable instead of an Iterator.
* Maybe Result.getRows() should allow for specifying offset and limit.
> Define query API
> ----------------
>
> Key: OAK-34
> URL: https://issues.apache.org/jira/browse/OAK-34
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Michael Dürig
> Labels: query
>
> Define a oak-core API for handling queries. How do we handle name space mappings, value bindings, limit, offset, access rights. See OAK-28
--
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
[ https://issues.apache.org/jira/browse/OAK-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245324#comment-13245324 ]
Michael Dürig commented on OAK-34:
----------------------------------
This would work
{code}
public interface Result<T extends ResultRow> extends Iterable<T> {
{code}
however it leaks the implementation into the API.
I think the idea was not to make Result itself extend from Iterable but rather to return an Iterable instead of an Iterator from getRows().
> Define query API
> ----------------
>
> Key: OAK-34
> URL: https://issues.apache.org/jira/browse/OAK-34
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Michael Dürig
> Labels: query
>
> Define a oak-core API for handling queries. How do we handle name space mappings, value bindings, limit, offset, access rights. See OAK-28
--
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
[ https://issues.apache.org/jira/browse/OAK-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245076#comment-13245076 ]
Thomas Mueller commented on OAK-34:
-----------------------------------
I have committed a first prototype. Some parts are still missing (for example offset and limit), and the CoreValue is still in the package org.apache.jackrabbit.oak.query. But I would like to get feedback first on the query part itself. Is it OK if the Result and ResultRow interfaces are in the package org.apache.jackrabbit.oak.api? Is the interface QueryEngine required, it should the two methods be moved to Connection? Are the interface and method names OK?
> Define query API
> ----------------
>
> Key: OAK-34
> URL: https://issues.apache.org/jira/browse/OAK-34
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Michael Dürig
> Labels: query
>
> Define a oak-core API for handling queries. How do we handle name space mappings, value bindings, limit, offset, access rights. See OAK-28
--
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