Le 06/04/11 00:02, Andreas Hahn a écrit :
Hi Vincent,ever thought of a users conference ?
That's a good idea..
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.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 ;)
It's worth discussing who would join. Ludovic
Am 05.04.2011 19:40, schrieb Vincent Massol: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.htmlSo? 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.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 ?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?Yes - sorry I mean XWQL - HQL is supported already and IMO that's sufficient although I may not be entitled to say that.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!Well - it's flagged as *MAJOR* . Are you saying that JIRA priority statements are meaningless and nobody doesn't care anyway ?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 -VincentAnyway, I'd like to say *THANK YOU* for the passion and supportive attitude here on the list. kind regards Andreasregards 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. CalebThe 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
<<attachment: ludovic.vcf>>
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
