4 Apr
2011
4 Apr
'11
4:47 p.m.
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
>
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost