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+Specification > > 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/QueryManager.html 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
