4 Apr
2011
4 Apr
'11
7:10 p.m.
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 :)
-Fabio
On Mon, Apr 4, 2011 at 6:47 PM, Ludovic Dubost <ludovic(a)xwiki.com> wrote:
Le 04/04/11 16:37, Caleb James DeLisle a écrit :
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On 04/04/2011 10:01 AM, Sergiu Dumitriu wrote:
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…
I will document it and publish it on extensions.xwiki.org
Ludovic
On 04/02/2011 02:22 PM, Caleb James DeLisle wrote:
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.
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. 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")
>> 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