On Mon, Apr 4, 2011 at 7:20 PM, Vincent Massol <[email protected]> wrote: > > 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 > Right.
> 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. > Yep. I am more towards an evolution of XWQL that progressively incorporates XWiki Data Model constructs (e.g., properties, comments, attachment, tag, etc.) and removes HQL/JPQL specific stuff (because HQL is tied to a very specific storage and could be impossible to translate it) Thanks, Fabio > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
