>FWIW I've played a bit with the Oak query code to see if its parsers >are reusable. > >That's not the case out of the box but it looks like refactoring Oak's >SQL2Parser and XPathToSQL2Converter to provide access to the abstract >syntax tree that they generate wouldn't be too hard. > >Going this way would allow us to reuse (a subset of) the JCR query >languages, instead of inventing yet another one.
with what goal? to not use a fluent API but stick with a query string and a new query syntax that is derived from oak query syntax, to help non-jcr provider parse the oak-style query and map it to their own query API? in my view the new query api was not intended to be a new query language, but a fluent API to build queries easier and this is mapped to any query language the underlying persistence supports. if compared to relational databases and JPA: this is the same reason why there is a query language JPQL and fluent Criteria API to do the same but without a query string. the first is more compact, the latter is easier to use for new user, and less error-prone. e.g. the fluent API takes care of parameter value escaping and other things, which is not the case if you built the query by hand (no "sql injection" attacks). and putting limits to what the query supports (compared to oak/JCR queries) was done by carsten by design. the goal was to support ~90% of all typical queries, not the most complex ones supported by oak/JCR, to make it easer for resource resolver implementations with not-so elaborated persistence engines. if we re-use the oak/JCR syntax we have to support 100% or end in a mess with only partially supporting it in some providers. stefan
