GeoTools
  1. GeoTools
  2. GEOT-602

Literal expression does not support Boolean and ...?

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.1.RC1
    • Fix Version/s: 2.7-M0
    • Component/s: main
    • Labels:
      None

      Description

      I don't know the specification perfectly but it seems to me that Booleans should be Literal objects as well. If boolean is missed are there any other obvious literals that are missing?

        Activity

        Hide
        Jesse Eichar added a comment -
        Allowing Comparable objects to be Literals is also a consideration. Although this would mean that the particular expression would no longer be able to be written out. However it does make Filters more flexible if they are not intended to be written to disk in a normal format.
        Show
        Jesse Eichar added a comment - Allowing Comparable objects to be Literals is also a consideration. Although this would mean that the particular expression would no longer be able to be written out. However it does make Filters more flexible if they are not intended to be written to disk in a normal format.
        Hide
        Gabriel Roldan added a comment -
        well, the Filter spec defines the xml encoding for the productions of the Common Query Language whose BNF is defined in the Catalog impl spec.
        There, literals are defined to be one of number, character string, datetime, boolean or geometry.

        So we lack at least Boolean and Date.

        Point it what to do when you have an attribute type that is not of one of those types, say, Locale. We can easily say that you have to use a kind of string canonical form for it, so you can encode a locale property as "en_US".
        Problem arised when you parsed a comparison filter and has to compare an AttributeExpression against a "normalized" literal, like in the case of Locale, but the literal is actually a String. Or evel worst, a function expression whose result if a Locale against a literal which is a String.
        As the possible types of the "normalized" literals are endless, it doesn't seems like an optimal solution to have a predefined set of comparison rules for objects of different types, similar to what we have in AttributeType.parse(Object). And we cannot use AttributeType.parse() inside ComparisonFilter since most of the time we'll don't have an AttributeExpression, or well the AttributeExpression will not have a reference to the AttributeType.

        So I would like to propose the use of commons-beanUtils' Converter framework to deal with this situation.

        ConvertUtils allows to register a Converter, used to convert String literals to instances of a given Class:
        http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.7.0/docs/api/org/apache/commons/beanutils/ConvertUtils.html

        There are a number of predefined converters for the most common cases, like URL, Long, Double, etc.
        http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.7.0/docs/api/org/apache/commons/beanutils/converters/package-summary.html

        This way, I could register a custom LocaleConverter and then I will be happy.

        Comments?



        Show
        Gabriel Roldan added a comment - well, the Filter spec defines the xml encoding for the productions of the Common Query Language whose BNF is defined in the Catalog impl spec. There, literals are defined to be one of number, character string, datetime, boolean or geometry. So we lack at least Boolean and Date. Point it what to do when you have an attribute type that is not of one of those types, say, Locale. We can easily say that you have to use a kind of string canonical form for it, so you can encode a locale property as "en_US". Problem arised when you parsed a comparison filter and has to compare an AttributeExpression against a "normalized" literal, like in the case of Locale, but the literal is actually a String. Or evel worst, a function expression whose result if a Locale against a literal which is a String. As the possible types of the "normalized" literals are endless, it doesn't seems like an optimal solution to have a predefined set of comparison rules for objects of different types, similar to what we have in AttributeType.parse(Object). And we cannot use AttributeType.parse() inside ComparisonFilter since most of the time we'll don't have an AttributeExpression, or well the AttributeExpression will not have a reference to the AttributeType. So I would like to propose the use of commons-beanUtils' Converter framework to deal with this situation. ConvertUtils allows to register a Converter, used to convert String literals to instances of a given Class: http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.7.0/docs/api/org/apache/commons/beanutils/ConvertUtils.html There are a number of predefined converters for the most common cases, like URL, Long, Double, etc. http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.7.0/docs/api/org/apache/commons/beanutils/converters/package-summary.html This way, I could register a custom LocaleConverter and then I will be happy. Comments?
        Hide
        Jody Garnett added a comment -
        Show
        Jody Garnett added a comment - Dicussion has started up in earnest: - http://docs.codehaus.org/display/GEOTOOLS/Expression+Improvements
        Hide
        Jody Garnett added a comment -
        The discussion mentioned above resolved the problem. In short filter is "typeless" and you always evaulate with an expected type in mind and the system will do its best to convert the result into a boolean if you want a boolean.
        Show
        Jody Garnett added a comment - The discussion mentioned above resolved the problem. In short filter is "typeless" and you always evaulate with an expected type in mind and the system will do its best to convert the result into a boolean if you want a boolean.

          People

          • Assignee:
            Cory Horner
            Reporter:
            Jesse Eichar
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: