OPTIMADE
OPTIMADE copied to clipboard
Grammar: Comparison of constant OPERATOR constant
I am having trouble understanding why and when it would be useful to compare number and strings to each other in the filter? Why should we support this?
It is currently OPTIONAL (see here). So is the identifier OPERATOR identifier comparison. This, however, I can see plenty of uses for; but when would it be useful to filter for, e.g., 5 < 7
?
I am as well a bit unsure whether we need this. I assume this is here just to be able to support all possible comparison combinations from set { property, identifier }
like most of programming languages do (SQL does, for instance). As the COD generally translates filters to SQL, I don't mind having this feature.
That's fair enough. And from an implementation point-of-view I see that it's easier just to include all, but it might be harmful, since it can be used as a "catch-'em-all". E.g., chemical_formula_descriptive CONTAINS "Al" OR 5 < 7
will completely disregard the first criteria. This might be transparent for the current example, but could in some cases result in a non-transparent result on the client side.
This has been discussed a bit in a quite long grammar thread (long as in, you may want to brew a cup of tea and sit down in a comfy chair before venturing forward), see #58.
I was initially for us enforcing the left hand side to always be an identifier, but I was (somewhat reluctantly) convinced that we should allow all variants, including constant OP constant.
The two best arguments to me are:
- A layer higher up may generate queries for you in the OPTiMaDe filter language. In implementing such a layer, there may be situations where it is natural to end up with constant OP constant constructs.
- When debugging a query, it may be useful to replace identifiers with constants to see how that affects the returned results.
Note that PR #229 now forbids string <op> string
, since it may be ambiguous. See discussion in #157 for how I personally hope we will solve that down the line (beyond 1.0).
Can we close this?