Of course it should be a common goal to make the query as useful as possible. I totally see the use cases for DISTINCT, lower, etc. I also agree to the fact that duplicating the whole grammar is not the best way to extend it.
On the other side I do not like that someone who just wants to implement a spec compliant query has to deal with our extensions. Perhaps we can find a way where we either have a default implementation that raises syntax errors or a mechanism in ANTLR to extend the grammar without duplication. I am not the ANTLR expert, but there might be something like composed grammars. I should investigate that. If someone has a good idea let us know. We also need to make clear somehow where we have introduced extensions then. Jens -----Original Message----- From: Florent Guillaume [mailto:[email protected]] Sent: Montag, 31. Mai 2010 15:09 To: chemistry-dev Subject: Re: Query grammar is not standard compliant Hi Jens, On Sun, May 30, 2010 at 10:56 PM, Jens Hübel <[email protected]> wrote: > while further investigating the grammar (for improved integration into > OpenCMIS) I detected some issues that I would like to get fixed: > 1) > DISTINCT is not allowed as keyword in CmiSQL I added it recently to the grammar because it's a useful extension (that some Nuxeo customers use). Please note that a backend implementing the grammar can very easily say "syntax error" if it doesn't want to support this non-spec-based extension. Without this, someone wanting to implement CMIS + DISTINCT would have to completely copy the whole grammar. > 2) > The rule "string value function" is no longer supported. It existed in > earlier versions of the spec but was removed. The grammar in our code does > not reflect this change in the specification. Having string value functions like LOWER and so on are also useful extensions to CMIS that it's nice to have in the grammar even though a standard backend would not implement them. > 3) > only allowed operator with any is "=". The rule "quantified comparison > predicate" was changed in the spec from allowing multiple comparison > operators to only allow "=". The grammar in our code does not reflect this > change in the specification. Same as above, it's a useful extension in Nuxeo that is better put in a basic grammar. > 4) > The grammar is also not yet complete (the full text part is missing). I added > a separate issue for this. Again this was added with later revisions of the > spec. Yes, fulltext is still missing. > I have done all changes except 4) locally and updated the gunit tests > accordingly. If there are no objections I will check-in the changes. I'd really like to keep the SQL grammar useful for all projects that will use CMIS, and that includes extension above and beyond CMIS for those that need it. Again, this doesn't harm in any way the backends that want to implement just the spec. > I have created two JIRA entries for these issues: > https://issues.apache.org/jira/browse/CMIS-212 > https://issues.apache.org/jira/browse/CMIS-213 > > Remarks: > > Change 2) has some implications: This change implies that functions like > LOWER(...) etc. are no longer permitted. Can someone remember the TC decision > for this change? ( I browsed the CMIS JIRA but could not find it). I seem to remember that it was to have simple semantics, LOWER introduces language issues that we didn't want to spend time specifying. > The grammar currently is quite loosely coupled to the rest of the code. There > are no dependencies on it from other unit tests or sub-projects. For the > future my suggestion is that a custom ANTLR grammar is a valid integration > point with opencmis (to allow custom specific enhanced features in the query > language). But for our internal code, tests and documentation it should > strictly be what the standard says. Ok then let's not implement DISTINCT, LOWER, ANY <> and so on for the in-memory and other backends, but please keep them in the ANTLR grammar. Florent -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
