Yeah, I think the main concern in GeoMesa is not the CQL formatting per-say, but that for any given Filter, the following test holds:

Assert.assertEquals(filter, ECQL.toFilter(ECQL.toCQL(filter))))

(or at least that they are equivalent, if not strictly equals)

Thanks,

Emilio

On 2/4/19 4:49 PM, Jim Hughes wrote:
Hi Jody, Devon,

Thanks for asking.  From chatting with Emilio, we don't think it'd affect anything in GeoMesa.

From a quick look at the ECQL reference, it looks like attributes with non-alphanumeric characters should be double-quoted: https://docs.geoserver.org/latest/en/user/filter/ecql_reference.html#attribute ?

Does that help any?

Devon, what does your unit test do? If it is calling CQL.toFilter and then CQL.toCQL and checking equality, that seems like an excellent unit test!

Cheers,

Jim


On 2/4/19 2:17 PM, Jody Garnett wrote:
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 <mailto: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
    <mailto: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



_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to