I would check with the GeoMesa project as they heavily rely on toCQL to package up query strings. As long as James (CCed) knows when making to upgrade fixing the issue should be fine.
James are you aware of this issue? Or has it not come up in your testing... On Mon, Feb 4, 2019 at 9:41 AM Devon Tucker <dtuc...@boundlessgeo.com> wrote: > Hi all, > > Working with the Filter -> CQL code recently (CQL.toCQL) I noticed that it > is not producing correct CQL for attribute names. For example the following > test case fails: > > https://gist.github.com/dvntucker/1d7f8c227eea44d9bd1563f0269e4b6a > > There are a number of issues here, but the biggest one is the > forward-slash instead of a period, which is not correct by the CQL spec. > Also, this identifier does not need to be quoted and I don't think quoting > identifiers is in the CQL spec either. > > It looks like this is mainly an artifact from the parsing phase, where the > periods are replaced with slashes to match XPath. I believe this part is > correct, but needs to be corrected when producing CQL output. My only worry > with changing this is potentially people relying on this behavior. Looking > through GS/GT, it doesn't appear that this code path (Filter->CQL) is used > a whole lot, and in fact where it is seems very likely to fail because of > this (forward slash in identifier doesn't parse). > > Anyone see an issue with fixing this behavior? > > Cheers, > Devon > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- -- Jody Garnett
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
