Cool, thanks for the clarification Andrea.
I do think we should try to be as backwards compatible as possible. And in
this case I don't think we really give up anything falling back to the old
CQL parser. Unless there are some false positives... cases where an ECQL
invalid filter is but is valid CQL that leads to an unintended result... I
can't think of any.
Also the client in this question is running different versions of
geoserver... 2.0.x and 2.1.x. So coming up with different syntaxes based on
version will be problematic for them.
So unless there are any strong objections I will push the change in.
-Justin
On Thu, Apr 7, 2011 at 9:50 AM, Andrea Aime <[email protected]>wrote:
> On Thu, Apr 7, 2011 at 5:25 PM, Justin Deoliveira <[email protected]>
> wrote:
> > Hi all,
> > Recently a client attempting to upgrade to gs 2.1 RC4 reported an issue
> with
> > cql filter handling. Long story short they are trying to use an attribute
> > named "id" (not a primary key) in a simple comparison filter and the ecql
> > parser chokes on it. I recall conversation around ecql and the handling
> of
> > attributes named "id" regarding the fact that ecql can do feature ids.
> But
> > can't find much in the docs or in jira.
> > I guess the question is this is intended with the switch to ecql? I would
> > assume not as it seems a regression. An easy fix would be to mirror ogc
> > filter parsing where we fall back onto the old filter parser if the new
> one
> > fails. We could do the same with the ECQL/CQL parsers.
> > Thoughts?
>
> There are a few small things that are not backwards compatible, like
> using "A eq 5"
> or using "id" as an attribute.
> For the attribute case afaik you just need to double quote it so that
> it does not
> get recognized as a keyword, e.g.:
>
> "id" = 5
>
> should work.
>
> I guess doing the fall back might be an option if we want to provide full
> backwards compatibility. Don't really see alternatives as ECQL has been
> around for long and at some point the fid filter encoding used ID as a
> keyword:
>
> ID IN ('states.1', 'states.2', ...)
>
> now the syntax is really just
>
> IN('states.1', 'states.2', ...)
>
> Cheers
> Andrea
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
> mob: +39 333 8128928
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
