AQL Type Checking (discussion)

During the AQL spec review, detected there is no specification about operators and errors due type mismatch, since currently there is nothing specified about type checking.

Here you can find different analysis points related to this topic, which we need to review, discuss and decide how to proceed in the SEC, trying not to break current implementations.

The goal is to provide guides to prevent AQL errors due incorrect types of nodes pointed by paths, variables, parameters and operators that are applied to those.

Discussion points:

1. For each operator, define to which data types could be applied, for instance, could “<“ be applied to a string?

2. Define how each operator should behave when applied to the allowed types, for instance if a “<“ could be applied to datetime, what means that $a < $b if $a and $b are datetimes? (current spec lacks formal definitions for many operators)

3. Since some operands are paths, we need to define previous points not in terms of the data used as arguments for the comparison or arithmetic operators, but in terms of the data types referenced by the path, for instance, for a/b/c < $a, we should check “<“ could be applied to the type referenced by a/b/c (could be many types!) and to the type of $a, but also that the type referenced by a/b/c and the type of $a are comparable types, maybe one is a number and the other one a string or date.

4. Define the meaning of not equals and how the comparison is done. Some programming languages for comparing equality check the value but also check the type, and when checking only the value, if the type is different, there is an automatic casting to correspondent values (PHP and JS use similar methods). If we need to check if two values are not equal: a. should that check the type? b. if the values have different type, should that return an error or the comparison should return “those are different”? Consider comparing 3 (int) to 3.0 (float), are equal? different? an error should be returned because type mismatch?

5. Similar considerations of previous points should be done when comparing two paths like a/b/c > d/e/f, should check the types are comparable? should return false if types do not match? or an error?

6. Type checking could be done at different times. At design time, AQL editors could check the query definition as it’s created and detect potential issues. At run-time, when all parameters are known, the final check could be done. Also, a missing piece of the spec is to define/declare the parameters also with type, if that is done, most of the checks could be done at design time, and the run-time check is to verify the provided value for a parameter complies with the parameter definition in the query. I think this is how everything should be defined formally. Right now query parameters are not controlled and anything could be provided.