[xwiki-devs] [proposal] Move away from XWQL, it is invalid JPQL (JPA) thus it is it's own (undefined) standard.
2 Apr
2011
2 Apr
'11
2:22 p.m.
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.
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
4 Apr
4 Apr
4:01 p.m.
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.
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.
- Is there any tool that allows mapping a JPQL or JDOQL query into other
query languages?
- 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?
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
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
4:37 p.m.
On 04/04/2011 10:01 AM, Sergiu Dumitriu wrote:
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
6:12 p.m.
On 04/04/2011 04:37 PM, Caleb James DeLisle wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On 04/04/2011 10:01 AM, Sergiu Dumitriu wrote:
OK then, +1 from me to move to a standard query language.
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
>
> 
6:47 p.m.
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
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
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
7:20 p.m.
New subject: [xwiki-devs] [proposal] Move away from XWQL, it is invalid JPQL (JPA) thus it is it's own (undefined) standard.
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-par…
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 <ludovic(a)xwiki.com> 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…
>
> 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
7:35 p.m.
On Mon, Apr 4, 2011 at 7:20 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Apr 4, 2011, at 7:10 PM, Fabio Mancinelli wrote:
Right.
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-par…
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 <ludovic(a)xwiki.com> 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…
>
> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5 Apr
5 Apr
7:17 p.m.
Again this is sort of scaring discussion to me.
For minimal benefits - and there is still no persuasive example around -
you want to sacrifice proven (to avoid the word 'standard') query
language implementations to provide an own 'exotic' implementation ?
This doesn't make any sense to me except that it might be more fun to
write such an implementation
as to fix all outstanding JIRA issues.
Hibernate HQL is documented on ~30 printed pages with quite some examples:
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/queryhql.html
The HQL chapter in Gavin King and Christian Bauers 'standard' 'Java
Persistence' book is about 50 pages long.
Both documentations sort of scratch the surface - they are still lacking
when it comes to writing real complex stuff.
aggregations / joins all the like ...
So - now you propagate a new QL. Maybe it is better - who knows ?
It's not useful if there is just a basic documentation.
Even with a very good documentation it needs to be learned and understood.
From the users point of view it would be more beneficial to focus
efforts on making XWiki more concise.
Just as an example this issue
http://jira.xwiki.org/jira/browse/XRENDERING-75
seems to be open since 2 years ...
Again I don't mean to criticize. But from time to time please try to see
your work through users glasses ...
regards
Andreas
Am 04.04.2011 16:37, schrieb Caleb James DeLisle:
On 04/04/2011 10:01 AM, Sergiu Dumitriu wrote:
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).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
7:40 p.m.
New subject: [xwiki-devs] [proposal] Move away from XWQL, it is invalid JPQL (JPA) thus it is it's own (undefined) standard.
Hi Andreas,
On Apr 5, 2011, at 7:17 PM, Andreas Hahn wrote:
Again this is sort of scaring discussion to me.
For minimal benefits - and there is still no persuasive example around -
you want to sacrifice proven (to avoid the word 'standard') query
language implementations to provide an own 'exotic' implementation ?
This doesn't make any sense to me except that it might be more fun to
write such an implementation
as to fix all outstanding JIRA issues.
Hibernate HQL is documented on ~30 printed pages with quite some examples:
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/queryhql.html
So? Java EE is also documented. That doesn't mean we should use it... We should use
what fits our needs. We've already talked a LOT in the past about HQL and listened to
a *LOT* of users telling us it's hard to use. This is what drove the creation of XWQL
a few years ago.
The HQL chapter in Gavin King and Christian Bauers
'standard' 'Java
Persistence' book is about 50 pages long.
Both documentations sort of scratch the surface - they are still lacking
when it comes to writing real complex stuff.
aggregations / joins all the like ...
So - now you propagate a new QL.
What new QL? Are you talking about XWQL (it's several years old)? Or are you talking
about Caleb's suggestion to add support for an existing well known QL instead?
Maybe it is better - who knows ?
It's not useful if there is just a basic documentation.
Even with a very good documentation it needs to be learned and understood.
From the users point of view it would be more beneficial to focus
efforts on making XWiki more concise.
Just as an example this issue
http://jira.xwiki.org/jira/browse/XRENDERING-75
seems to be open since 2 years ...
This is a bad example. This issue has been there for 2 years because it's not really
needed!
Macros already support parameters and in addition format parameters are supported for
inline and if you need them for standalone it's also possible using groups:
(% ... %)(((
{{macro/}}
)))
Again I don't mean to criticize. But from time to
time please try to see
your work through users glasses ...
I think you're mistaken about a few things here:
1) this is a discussion started by someone. We're not refusing discussions be them
from users, contributors or committers. Nothing has been agreed. Why would we close
discussions and told people to shut up because they're not talking about something
that one user considers not useful?
2) why do you say we (as in xwiki committers) don't see through "user
glasses". We keep doing this all the time. Look around at all the issues that are
closed every day and that are user specific.
3) Developers need to think about a lot more things than you have to think about as a
user: stability of the platform, performance, api design (since it's a web development
platform), maintenance, etc. We need to think a few years ahead of users. With a reasoning
like "we fix only user stuff and don't do anything not directly
user-related" you wouldn't have a lot of things you like in xwiki and we would be
lagging behind other wikis.
So please don't generalize. If you have a specific wish/need please state it. You
mentioned XRENDERING-75 above and I've answered you (I already did on another thread
btw).
Thanks
-Vincent
regards
Andreas
Am 04.04.2011 16:37, schrieb Caleb James DeLisle:
>
> 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")
>>>
>>>
>>> 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
6 Apr
6 Apr
12:02 a.m.
Hi Vincent,
ever thought of a users conference ?
Its a bit exhausting discussing stuff like this on a mailing list ...
Well - if you ever plan to held one you can count on me if it's in one
of the famous french ski ressorts.
Earlier this year I'd been to Portes du soleil -Avoriaz - Morzine ..
e.t.c - you can count on me during the season ;)
Am 05.04.2011 19:40, schrieb Vincent Massol:
Yes - sorry I mean XWQL - HQL is supported already and IMO that's
sufficient although I may not be entitled to say that.
Well - it's flagged as *MAJOR* . Are you saying that JIRA priority
statements are meaningless and nobody doesn't care anyway ?
Anyway, I'd like to say *THANK YOU* for the passion and supportive
attitude here on the list.
kind regards
Andreas
Hi Andreas,
On Apr 5, 2011, at 7:17 PM, Andreas Hahn wrote:
Can you please point me to a document that explains XWQL - its
abstraction details considering XWikis Meta data model, the differences
to HQL or JPQL other than the trivial examples shown here:
http://incubator.myxwiki.org/xwiki/bin/view/XWQL/WebHome
From this document
http://platform.xwiki.org/xwiki/bin/view/DevGuide/QueryGuide
it seems to me that XWQL does ~some undocumented magic due to XWikis
meta data-model that might be reasonable or not - but where is the
explanation ?
Again this is sort of scaring discussion to me.
For minimal benefits - and there is still no persuasive example around -
you want to sacrifice proven (to avoid the word 'standard') query
language implementations to provide an own 'exotic' implementation ?
This doesn't make any sense to me except that it might be more fun to
write such an implementation
as to fix all outstanding JIRA issues.
Hibernate HQL is documented on ~30 printed pages with quite some examples:
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/queryhql.html
So? Java
EE is also documented. That doesn't mean we should use it... We should use what fits
our needs. We've already talked a LOT in the past about HQL and listened to a *LOT* of
users telling us it's hard to use. This is what drove the creation of XWQL a few years
ago.
The HQL
chapter in Gavin King and Christian Bauers 'standard' 'Java
Persistence' book is about 50 pages long.
Both documentations sort of scratch the surface - they are still lacking
when it comes to writing real complex stuff.
aggregations / joins all the like ...
So - now you propagate a new QL.
What new QL? Are you talking about XWQL (it's
several years old)? Or are you talking about Caleb's suggestion to add support for an
existing well known QL instead?
Maybe it is
better - who knows ?
It's not useful if there is just a basic documentation.
Even with a very good documentation it needs to be learned and understood.
From the users point of view it would be more beneficial to focus
efforts on making XWiki more concise.
Just as an example this issue
http://jira.xwiki.org/jira/browse/XRENDERING-75
seems to be open since 2 years ...
This is a bad example. This issue has been
there for 2 years because it's not really needed! Macros already support parameters and in addition
format parameters are supported for inline and if you need them for standalone it's
also possible using groups:
(% ... %)(((
{{macro/}}
)))
Again - another 'pitfall' in my eyes (at least in terms of documentation)
I've learned that this artifact always renders to wrapping the macro in
<div> {{macro}} </div> enclosures
instead of passing any parameters
(% ... %) (((
{{macro}}
)))
but this artifact (inline) passes parameters to the macro
(% ... %) {{macro}}
while this artifact (standalone) is not supported (not needed ?)
(% ... %)
{{macro}}
That's what I mean that from a users POV XWiki might well deserve to
become more 'concise'.
Again I
don't mean to criticize. But from time to time please try to see
your work through users glasses ...
I think you're mistaken about a few things
here:
1) this is a discussion started by someone. We're not refusing discussions be them
from users, contributors or committers. Nothing has been agreed. Why would we close
discussions and told people to shut up because they're not talking about something
that one user considers not useful?
2) why do you say we (as in xwiki committers) don't see through "user
glasses". We keep doing this all the time. Look around at all the issues that are
closed every day and that are user specific.
3) Developers need to think about a lot more things than you have to think about as a
user: stability of the platform, performance, api design (since it's a web development
platform), maintenance, etc. We need to think a few years ahead of users. With a reasoning
like "we fix only user stuff and don't do anything not directly
user-related" you wouldn't have a lot of things you like in xwiki and we would be
lagging behind other wikis.
So please don't generalize. If you have a specific wish/need please state it. You
mentioned XRENDERING-75 above and I've answered you (I already did on another thread
btw).
Thanks
-Vincent
regards
Andreas
Am 04.04.2011 16:37, schrieb Caleb James DeLisle:
> 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")
>>>
>>>
>>> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:47 a.m.
Le 06/04/11 00:02, Andreas Hahn a écrit :
Hi Vincent,
ever thought of a users conference ?
That's a good idea..
Its a bit exhausting discussing stuff like this on a
mailing list ...
Well - if you ever plan to held one you can count on me if it's in one
of the famous french ski ressorts.
Earlier this year I'd been to Portes du soleil -Avoriaz - Morzine ..
e.t.c - you can count on me during the season ;)
Now I'm not sure that ski
resorts that are 6 hours away from Paris in
train would be best (though I skied in Avoriaz too :)) if we want to get
non french people out there.
It's worth discussing who would join.
Ludovic
Am 05.04.2011 19:40, schrieb Vincent Massol:
Yes - sorry I mean XWQL - HQL is supported already and IMO that's
sufficient although I may not be entitled to say that.
Well - it's flagged as
*MAJOR* . Are you saying that JIRA priority
statements are meaningless and nobody doesn't care anyway ?
Anyway, I'd like to say *THANK YOU* for the passion and supportive
attitude here on the list.
kind regards
Andreas
_______________________________________________
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
Hi Andreas,
On Apr 5, 2011, at 7:17 PM, Andreas Hahn wrote:
Can you please point me to a document that explains XWQL - its
abstraction details considering XWikis Meta data model, the differences
to HQL or JPQL other than the trivial examples shown here:
http://incubator.myxwiki.org/xwiki/bin/view/XWQL/WebHome
From this document
http://platform.xwiki.org/xwiki/bin/view/DevGuide/QueryGuide
it seems to me that XWQL does ~some undocumented magic due to XWikis
meta data-model that might be reasonable or not - but where is the
explanation ?
Again this is sort of scaring discussion to me.
For minimal benefits - and there is still no persuasive example around -
you want to sacrifice proven (to avoid the word 'standard') query
language implementations to provide an own 'exotic' implementation ?
This doesn't make any sense to me except that it might be more fun to
write such an implementation
as to fix all outstanding JIRA issues.
Hibernate HQL is documented on ~30 printed pages with quite some examples:
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/queryhql.html
So? Java
EE is also documented. That doesn't mean we should use it... We should use what fits
our needs. We've already talked a LOT in the past about HQL and listened to a *LOT* of
users telling us it's hard to use. This is what drove the creation of XWQL a few years
ago.
The HQL
chapter in Gavin King and Christian Bauers 'standard' 'Java
Persistence' book is about 50 pages long.
Both documentations sort of scratch the surface - they are still lacking
when it comes to writing real complex stuff.
aggregations / joins all the like ...
So - now you propagate a new QL.
What new QL? Are you talking about XWQL (it's
several years old)? Or are you talking about Caleb's suggestion to add support for an
existing well known QL instead?
Maybe it
is better - who knows ?
It's not useful if there is just a basic documentation.
Even with a very good documentation it needs to be learned and understood.
From the users point of view it would be more beneficial to focus
efforts on making XWiki more concise.
Just as an example this issue
http://jira.xwiki.org/jira/browse/XRENDERING-75
seems to be open since 2 years ...
This is a bad example. This issue has been
there for 2 years because it's not really needed! Macros already support parameters and in addition
format parameters are supported for inline and if you need them for standalone it's
also possible using groups:
(% ... %)(((
{{macro/}}
)))
Again - another 'pitfall' in my eyes (at least in terms of documentation)
I've learned that this artifact always renders to wrapping the macro in
<div> {{macro}}</div> enclosures
instead of passing any parameters
(% ... %) (((
{{macro}}
)))
but this artifact (inline) passes parameters to the macro
(% ... %) {{macro}}
while this artifact (standalone) is not supported (not needed ?)
(% ... %)
{{macro}}
That's what I mean that from a users POV XWiki might well deserve to
become more 'concise'.
Again I
don't mean to criticize. But from time to time please try to see
your work through users glasses ...
I think you're mistaken about a few things
here:
1) this is a discussion started by someone. We're not refusing discussions be them
from users, contributors or committers. Nothing has been agreed. Why would we close
discussions and told people to shut up because they're not talking about something
that one user considers not useful?
2) why do you say we (as in xwiki committers) don't see through "user
glasses". We keep doing this all the time. Look around at all the issues that are
closed every day and that are user specific.
3) Developers need to think about a lot more things than you have to think about as a
user: stability of the platform, performance, api design (since it's a web development
platform), maintenance, etc. We need to think a few years ahead of users. With a reasoning
like "we fix only user stuff and don't do anything not directly
user-related" you wouldn't have a lot of things you like in xwiki and we would be
lagging behind other wikis.
So please don't generalize. If you have a specific wish/need please state it. You
mentioned XRENDERING-75 above and I've answered you (I already did on another thread
btw).
Thanks
-Vincent
regards
Andreas
Am 04.04.2011 16:37, schrieb Caleb James DeLisle:
> 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")
>>>
>>>
>>> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:01 a.m.
Le 05/04/11 19:17, Andreas Hahn a écrit :
Again this is sort of scaring discussion to me.
For minimal benefits - and there is still no persuasive example around -
you want to sacrifice proven (to avoid the word 'standard') query
language implementations to provide an own 'exotic' implementation ?
Implementing an XWiki QL based on any standard won't be that easy either.
There is a good change that for time constraint that would lead to a
"partial" implementation of the "standard".
This doesn't make any sense to me except that it
might be more fun to
write such an implementation
as to fix all outstanding JIRA issues.
It's not about fun. This has been pushed
back for long and we need it
for other backends.
Hibernate HQL is documented on ~30 printed pages with
quite some examples:
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/queryhql.html
The HQL chapter in Gavin King and Christian Bauers 'standard' 'Java
Persistence' book is about 50 pages long.
Both documentations sort of scratch the surface - they are still lacking
when it comes to writing real complex stuff.
aggregations / joins all the like ...
So - now you propagate a new QL. Maybe it is better - who knows ?
It's not useful if there is just a basic documentation.
Even with a very good documentation it needs to be learned and understood.
The JDOQL or JPQL document will partially help you since anyway you'll
have to learn the right structures to use (xObjects etc..)
That won't stop us to write a documentation.
We have exactly that problem with HQL.
We need a new QL because we need to abstract from HQL, if we want to be
able to have alternate backends like cloud backends (Google AppEngine,
Cassandra, etc..)
From the users point of view it would be more
beneficial to focus
efforts on making XWiki more concise.
Just as an example this issue
http://jira.xwiki.org/jira/browse/XRENDERING-75
seems to be open since 2 years ...
It won't help the debate to dismiss it based
on priorities.
Writing queries is one of the things developers do most when they write
XWiki application.
All in all it's a lot time waster writing unreadable long queries in HQL.
Again I don't mean to criticize. But from time to
time please try to see
your work through users glasses ...
Thinking about the user (developer in this case) is the rationale behind
working on XWQL
Ludovic
regards
Andreas
Am 04.04.2011 16:37, schrieb Caleb James DeLisle:
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
On 04/04/2011 10:01 AM, Sergiu Dumitriu wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5009
days inactive
5013
days old
12 comments
6 participants
participants (6)
-
Andreas Hahn -
Caleb James DeLisle -
Fabio Mancinelli -
Ludovic Dubost -
Sergiu Dumitriu -
Vincent Massol