On Apr 4, 2011, at 7:10 PM, Fabio Mancinelli wrote: > Hi, > > I agree with Ludovic... > > From my point of view XWQL is an XWiki-specific DSL that abstracts the > underlying XWiki Data Model and allows you to write declarative > queries for retrieving XWiki data using the XWiki vocabulary. I see > HQL compatibility as a "backdoor" to write queries for things that are > not yet expressable with some XWQL constructs. Something that is not > really necessary and that we should get rid of eventually. > > Ideally HQL should disappear in the background when XWQL will be > enough expressive to cover all the XWiki Data Model. > > With a powerful XWQL where every query in XWiki is expressed in XWQL, > the underlying persistence mechanism could be changes (provided that > there is a driver for translating XWQL to something that is able to > retrieve data in the underlying persistence layer) > > Going to the DataNucleus stuff... DataNucleus provides an abstraction > layer that allows to map JDO/JPA annotated models to be persisted > using different storages. > Now this is about the "lower part" of the architecture. On the upper > part there will be a driver that takes an XWQL and spits the needed > query for retrieving data using JDOQL (i.e., DataNucleus' query > language). > > Basically DataNucleus would provide drivers for mapping JDO/JPA and > their query languages to different storages. We need to provide > drivers to XWQL to JDOQL. > > I agree that we should define what XWQL is and make the current > version evolve towards this definition :) > > One thing that could be useful is to search the current XWiki > distribution for all the queries done in scripts and try to extract > patterns from the results. > An XWQL definition that covers 80% of these queries would be great :)
Well isn't XWQL is already defined and specified: http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-query/jpql-parser/src/main/sablecc/JPQL.grammar What you suggest Fabio would be equivalent to creating a new QL (or maybe a new version of XWQL in the same manner as we have XWiki Syntax 2.0 and XWiki Syntax 2.1), unless I'm mistaken or didn't understand something. Thanks -Vincent > -Fabio > > > > On Mon, Apr 4, 2011 at 6:47 PM, Ludovic Dubost <[email protected]> wrote: >> Le 04/04/11 16:37, Caleb James DeLisle a écrit : >>> >>> On 04/04/2011 10:01 AM, Sergiu Dumitriu wrote: >>>> >>>> On 04/02/2011 02:22 PM, Caleb James DeLisle wrote: >>>>> >>>>> After searching through documentation on JPQL (JPA's query language) I >>>>> was unable to find any >>>>> example of the "doc.object(XWiki.XWikiUsers)" construct. This means XWQL >>>>> is it's own standard and >>>>> there is no authoritative reference on it. What makes an implementation >>>>> compliant? I have found that >>>>> most HQL queries can be executed as XWQL queries with little or no >>>>> modification so if compliance is >>>>> defined as being "just like the reference implementation" then nearly >>>>> all HQL must be implemented in >>>>> order to be compliant. >>>> >>>> The goal of XWQL was to not be bound to a certain query language, but to >>>> be able to map it to as many QLs as possible, be they SQL-related, like >>>> HQL or JPQL, or other types of queries, like QBE, XPath, SPARQL. So, it >>>> wasn't meant from the start to be compatible with any standard. >>> >>> The problem now is we don't have any specification to tell us what is >>> valid and what is not. >>> Is this a valid XWQL query? >>> >>> $services.query.xwql("from BaseObject as obj where doc.fullName = obj.name >>> and obj.className = >>> 'XWiki.XWikiUsers'").execute() >>> >>> Run it and you might be surprised. >>> Based on that, we have no way of ensuring that a query which works now >>> will work in a new XWQL >>> implementation which defeats the purpose of abstracting the user away from >>> HQL. >>> >>>> Now, I'm not sure if the right thing to do is to move to a standard >>>> query language, or to stick with our own. >>> >>> If we're going to define our own query language (I think there are enough >>> already) there are certain >>> things we have to do such as writing a specification. I frankly find this >>> thing embarrassing. >>> >>>> - Is there any tool that allows mapping a JPQL or JDOQL query into other >>>> query languages? >>> >>> http://www.datanucleus.org/products/accessplatform_3_0/datastores.html >>> These folks are mapping JDOQL and JPQL into a whole bunch of different >>> types of storage. >>> >>>> - Is there a way to parse a query into a tree/AST? >>>> - Other than the fact that it's a non-standard language (and all the >>>> consequences of this, like no support from tools and libraries), are >>>> there any downsides to having our own query language? >>> >>> This particular one has 2 downsides: >>> 1. There is no official specification. >>> 2. HQL can be run as shown above. >>> >>> The major downside of implementing one correctly is that it is massively >>> complicated. >>> >>> Caleb >>> >>>> The benefit of XWQL was that it allowed to write domain specific >>>> queries, which are shorter and easier to understand (at least in theory). >>>> >>>>> Looking at the specifications I have rewritten the example query in >>>>> compliant JPQL and JDOQL. >>>>> I wrote these so that they would work if all objects were custom mapped >>>>> which is similar to the >>>>> appearance XWQL gives. >>>>> >>>>> XWQL: >>>>> (SELECT doc.fullName FROM XWikiDocument as doc) where doc.author = >>>>> 'XWiki.LudovicDubost' and >>>>> doc.object(XWiki.XWikiUsers).email like '%xwiki.com' >>>>> >>>>> JPQL: >>>>> SELECT doc.fullName FROM XWikiDocument as doc, IN(doc.xObjects) obj >>>>> WHERE obj.className = >>>>> 'XWiki.XWikiUsers' and obj.email LIKE '%xwiki.com' >>>>> >>>>> JDOQL: >>>>> SELECT this.fullName FROM XWikiDocument WHERE >>>>> this.xObjects.containsValue(obj)&& obj.className == >>>>> "XWiki.XWikiUsers"&& obj.email.startsWith("xwiki.com") >>>>> >> >> The key objective of XWQL is to abstract from the XWiki point of view and >> make it as simple as possible to write queries. >> If I take this (valid) query in XWQL: >> >> from doc.object(Blog.BlogPostClass) as blogarticle where 'Blog.Blogging' >> member of blogarticle.category >> >> It seems to me that it would be more complex in JPQL or JDOQL, which is not >> very cool. >> I'm -1 from any new query language that would end up being more complex. >> >> If I take your 2 downsides: >> >> 1/ Official spec >> >> Well we should write one. It seems normal to me that a new query language >> has no spec. >> But this does not mean that we don't need a language. >> >> Unless we can find a standard language that is as easy to use as XWQL, let's >> stick to XWQL. >> If we need to improve XWQL let's improve it. >> >> 2/ HQL can be run >> >> That's an implementation issue. XWQL's objective is to write and run after >> translations to whatever is needed by the backend. >> It is VERY important to have a simple query language. It took a long time to >> learn how to run joins in HQL which are not needed from a pure "functionnal" >> standpoint. >> >> BTW I had fixed XWiki's query generator which now generates XWQL. It needs >> XWiki 2.7.1+ >> >> Example here: >> >> http://www.ludovic.org/xwiki/bin/view/Test/Query?query=1&classname=Blog.BlogPostClass&Blog.BlogPostClass_title=&Blog.BlogPostClass_content=&Blog.BlogPostClass_extract=&Blog.BlogPostClass_category=Blog.Blogging&Blog.BlogPostClass_publishDate_morethan=&Blog.BlogPostClass_publishDate_lessthan= >> >> I will document it and publish it on extensions.xwiki.org >> >> Ludovic >> >> >>>>> I understood that XWQL was simply a translation scheme which made it >>>>> appear that we were using JPQL >>>>> with the schema we wanted when really we were using HQL with the schema >>>>> we had. Given that it is not >>>>> compliant JPQL that is not the case. >>>>> >>>>> I think when we update the schema, we should cut our losses with this >>>>> thing and move to something >>>>> which has a reference document and is more widely used. >>>>> >>>>> WDYT? >>>>> >>>>> Caleb >>>>> >>>>> >>>>> >>>>> The JPQL specification (originally called EJBQL): >>>>> ejb-3_0-fr-spec-ejbcore.pdf chapter 9. >>>>> http://jcp.org/aboutJava/communityprocess/final/jsr220/ >>>>> >>>>> The JDOQL specification: >>>>> jdo-3_0-mrel3-spec.pdf chapter 26. >>>>> http://db.apache.org/jdo/specifications.html >>>>> >>>>> Easy to read, example rich descriptions: >>>>> http://www.datanucleus.org/products/accessplatform_3_0/jpa/jpql.html >>>>> http://www.datanucleus.org/products/accessplatform_3_0/jdo/jdoql.html _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
