Hi Artem,
On May 15, 2008, at 9:10 PM, Artem Melentyev wrote:
Hi, devs.
I'm working on JCRStore and QueryPlugin and I want to get some
feedback
about
http://dev.xwiki.org/xwiki/bin/view/Design/XWiki+Query+Language+Specificati…
1. Why our QueryPlugin's xpath isn't sufficient? (except it doesn't
work
now and some features are unimplemented :))
Using xpath would be definitely easier to implement. However I agree
it's not very user-friendly.
2. Are we sure to use sql-like query language?
I think sql isn't user friendly language.
SQL-like is going to be quite hard to implement (we'll need to use a
JavaCC or Antlr grammar) but it's probably slightly more user-
friendly, but not perfect either. The hard part is going to ensure
that the grammar is complete IMO and the mapping with the underlying
storage implementation (JCR or Hibernate).
Also many features of sql (such as joins) is
impossible for JCR.
In that case, we should probably make our query module generic and
independent of the storage module. Then the SPI implementations for
the given storage modules can restrict what's allowed and what's not
allowed maybe?
The mapping is really going to be the hard part.
3. What user query language would you prefer for
xwiki?
I think we should offer an even simpler DSL for querying objects and
object properties in xwiki documents that can be used by non
developers. Either something like
http://code.xwiki.org/xwiki/bin/view/Macros/RequestStructuredDocumentsMacro
or a generic query language but very simple and working only on
documents, objects and classes.
More generally:
I'd really like that we have a design that supports multiple query
languages by having a QueryManager component designed like
http://www.day.com/maven/jsr170/javadocs/jcr-1.0/javax/jcr/query/QueryManag…
In that way we could support XPath, SQL and the new query language
we're talking about.
I sent the following mail below on September 2007 about this but I
couldn't find it on nabble or markmail so maybe it never reached the
list for some reason:
===start here====================
Hi,
I'd like to start designing the v2 of the Storage/Query API.
Current issues:
=============
* Current XWikiStoreInterface is too broad, having business methods
for anything that can retrieved from the store.
* Business methods should be located in the Model. For example,
getDocumentNames() should be located in the Wiki object representing a
wiki.
* There's currently no object for manipulating queries so there are
lots of duplications
Requirements:
============
* Solve current issues listed above
* The store interface should be simple and have a minimal number of
method. I can imagine one for now: List executeQuery(Query query);
* It should allow for new query languages and support the current HQL
syntax
Proposal:
========
* Create a new module in core called xwiki-store
* Use the new component model
* Have the following classes/interfaces in it:
- Store
List executeQuery(Query)
- HibernateStore: implementation of Store for Hibernate
- CacheStore: caching implementation of Store
- Query (interface)
- HibernateQuery: implementation of Query for HQL
- (later) JCRQuery: implementation of Query for JCR
Usage:
======
HibernateQuery query = new HibernateQuery("select * from ....");
query.addParameter(index, value); // for named HQL queries
List results = store.execute(query);
Notes:
======
* This proposal is backward compatible with current code
* Slowly move current code to use the new code, deprecating methods/
classes as we progress
* There are some overlaps with the query plugin