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: > 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. > 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 > -Vincent > Anyway, I'd like to say *THANK YOU* for the passion and supportive attitude here on the list. kind regards Andreas >> 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
