Support for JPQL Functions on Query Conditions

[MRichards99]

Since my last PR, I went back and made some changes to my implementation of #86. I've created a new branch for this as we would like to target this for a 0.20.0 but also it was easier for me to start from a fresh branch.

The changes mean that when conditions are put into self.conditions, the key of the condition becomes a tuple:
{("title", "UPPER"): "like '%PolICE%'"}

This means that a user can create a condition in the same way that they do in 0.19.0. A user will not notice any difference with these changes, but they will be able to make use of the new feature if desired.

Where self.conditions is accessed, I have made changes to work with the new key format, particularly in __str__.

I've tried to address all of your comments of my previous implementation:

• I've added a test in test_06_query.py (dac6a3d & ce68126) - this tests the functionality on an attribute as well as an attribute from a related entity. It uses the UPPER() function which is DataGateway's intended use case for this. I did also test LENGTH() for the tutorial which worked but didn't add this as a explicit test
• I've created a dedicated function to split the attribute name from the function name, _split_db_functs (851fef2)
• I've made sure the split function is only executed where for the query conditions (e141e54). It is only called in addConditions() as this is the only intended place for this feature for the moment. There are no calls in low level functions now.
• I have also documented this in the docstring of addConditions() and the tutorial (c825b80)

[RKrahl]

Many thanks for submitting this. I still have however a few issues:

• most importantly, I'd like to keep the keys of query.conditions to be the attributes that the conditions are set on, see comment on line 414.
• I'd prefer the parsing in _split_db_functs() to be more explicit, using a regular expression.
• as suggested in a comment in #87, it might make sense to allow JPQL functions also in order. We could also add that as we are on it.
• some minor things as commented in the code.

There is also a case where the implementation fails:

# search for User whose name is longer than 11 characters and comes later the "C" in alphabethic order.
>>> query = Query(client, "User", conditions={"LENGTH(fullName)": "> 11", "fullName": "> 'C'"})
>>> str(query)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/abuild/test/python-icat-0.19.1.dev6+gc825b80/build/lib/icat/query.py", line 515, in __str__
    for a, jpql_funct in sorted(self.conditions.keys()):
TypeError: '<' not supported between instances of 'NoneType' and 'str'

This seem to be related with using tuples of attribute names and JPQL functions in the keys of query.conditions, e.g. my first bullet above.

[RKrahl]

@MRichards99, note that as I already hinted before, you don't need to do all the work alone. I have an idea on how to organize query.conditions to include the JPQL functions and might come up with a suggestion for an implementation this week.

[RKrahl]

Supersedes and closes #87.

[MRichards99]

Thanks for looking at this. I understand each of your points and thank you for starting to make some additional changes in #92. I will be happy to review your changes once you've finished them, just make the PR ready for review when you're finished :)

[RKrahl]

Basically, I assume that this fine now. I'll need to check it again though and there is also still some minor cleanup to do. This week is pretty busy with Virtual SciDataCon 2021, LEAPS plenary and ExPaNDS PID workshop, so I won't make any promisses when I'll get around to do this.

[RKrahl]

Looks good for me now.

[MRichards99]

Brilliant, I'll let you merge this when you're ready if that's okay, just so we don't confuse each other regarding Python ICAT's release process.

[RKrahl]

Actually, I already merged it into release/0.20.0. This is the branch that collects all changes for 0.20.0 and will be merged into master at the moment of the release.