Review structure of Query.conditions

[RKrahl]

This amends #89:

• do not store the JPQL function in the key of Query.conditions but rather set the value to a template string including the JPQL function when present,
• simplify the code by storing the values of Query.conditions always as a list, even if there is only one single condition,
• use a regular expression to parse optional JPQL function and attribute.

This addresses the first two bullets in my review of #89 and as a side effect also fixes the error case mentioned in the review. I still might add a few more changes, in particular implementing support for JPQL functions also in order, hence the draft status.

[RKrahl]

I now also added JPQL function support for order.

[MRichards99]

I'm generally happy with this, but could you update the docstring for addConditions as per my comment please?

[MRichards99]

Please could you change this documentation to remove the section which states that the key could be a string or list of strings? Due to the list comprehension introduced on line 444, the condition key will always be a list, even if it only contains a single string. For example, query.addConditions({"id": "> '5'"}).

I noticed this when running the tests on DataGateway API.

[RKrahl]

I beg to differ. As for any other method, the docstring of addConditions() documents the arguments that the method accepts. It does not document the internal data structures in the attributes of a Query object. These are intentionally left undocumented and thus whetever happens in line 444 is not relevant here. The conditions argument to addConditions() must be a mapping of attribute names to conditions, where the conditions in turn may either be simple strings or list of strings. So this docstring is correct. Your example query.addConditions({"id": "> '5'"}) in fact demonstrates that a simple string value will be accepted.

[MRichards99]

Yes, that is something which I didn't initially consider when reading the docstring. I think I was slightly surprised that all keys in self.conditions will always be a list of strings, although I don't think this is a problem. I fixed the tests on DataGateway API and everything behaves as I expect.

[RKrahl]

In any case, we will need to mention in the changelog that the internal data structures in the Query class have changed. This also has an impact on the formal string representation operator __repr__(). I'm going to open another issue on the latter, even if only for the sake of documentaion.