On Thu, Apr 7, 2011 at 10:38 PM, Justin Deoliveira <[email protected]> wrote: > 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.
Works for me. We may possibly want to have a centralized CQL like class for GeoServer code to parse/generate CQL/ECQL? Afaik now there are only two call points, but CQL is common and we might start seeing it pop up in other plugin/extension configurations 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 ------------------------------------------------------- ------------------------------------------------------------------------------ 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
