Add OR Functionality to Conditions
Closed this issue · 4 comments
As I'm sure you're aware, the ExPANDS search API requires the and and or keywords to be supported for the API's WHERE query filter. Python ICAT supports AND already, but does not support OR. For our implementation of the search API, we would need this functionality to be added to Python ICAT.
I'm just opening this issue for awareness :)
This one is difficult.
As you may have noticed by now, I am keen to keep the API of class Query clean and consistent. Query is a helper that is supposed to make it easy to build JPQL query strings. If its API becomes too complicated, the class becomes useless, then it will be easier to build query strings right away. Obviously, the simplicity comes at the cost that Query will never be able to support the full flexibility and complexity of all JPQL expressions.
Supporting OR in the conditions immediately demands nested expressions such as a AND (b OR (c AND d)). I have no idea how something like that could be expressed in the keyword arguments to Query() without resorting to completely convoluted data structures in these arguments.
Yes I agree, nested expressions will be complex, although it looks like this functionality is needed for the search API.
In the PaNOSC documentation for the where filter, nested expressions are not covered or explicitly mentioned so I did wonder if implementing solution choosing a single logic operator within a single query would be acceptable. However, in one of the dataset example queries, the where filter contains a nested expression so I'm guessing they do need to be supported. This may have been obvious but I was keen to explore different avenues which may make things easier (for both of us) for a first release of the search API.
Like you, I'm unsure what the correct solution is to this at this point in time, but I'll continue to have a think about what can be done on Python ICAT so the search API can support this functionality.
One option to consider might be to write a dedicated query translator for the search API rather than using the general purpose class Query(). If the source of the query is known, the implementation of the query builder may be easier, because you are able to hardcode assumptions on the data structure of that source.
We wont implement this for the time being.