It would be a change, one I think is in the spirit of ECQL (making a text representation of the full range of geotools filter api).
Are you sure you should not be changing that to be an expression? (just doing attribute or function does not fully cover all the kinds of expressions that ECQL could allow here). -- Jody Garnett On Mon, 18 Feb 2019 at 14:56, Emilio Lahr-Vivaz <elahrvi...@ccri.com> wrote: > Hello, > > I've hit a bug in the GeoTools ECQL parsing. I've got a fix, but wanted > to raise the issue here before opening a pull request. > > We've got a custom filter function named 'proxyId', which just hashes > the feature ID into an int. We use it for reach-back queries, so we can > save bandwidth on sending lots of feature IDs to the client. So for a > given feature returned with a proxy ID (in place of a regular ID), we > can construct a query using the default geometry and use the proxyId to > disambiguate any other features that have the same geometry. The bug > shows up in the ECQL round-trip, when querying multiple ids at once. > ECQL.toCQL turns the filter from "proxyId() = 0 OR proxyId() = 1" into > "proxyId() IN (0, 1)", which then fails to parse with ECQL.toFilter(). > To fix it, I've added a check for "Function()" in the ECQLGrammar class > here: > > https://github.com/geotools/geotools/blob/master/modules/library/cql/src/main/jjtree/ECQLGrammar.jjt#L469 > > Does that seem reasonable? If so, I'll open a formal PR. > > Thanks, > > Emilio > > > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel >
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
