6 Apr
2011
6 Apr
'11
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