Implement Distinct Filter for Python ICAT Backend

[MRichards99]

This PR closes #141.

This adds functionality for the distinct filter. Like the database backend, either a single field can be used, or a list of fields can be entered to be "distinct". Multiple distinct filters can be used in a single request without them overwriting each other, which I didn't expect I could do at the start of looking at this issue, so that's good :)

Since Python ICAT only really supports a single field to be distinct (through the use of setAttribute() and setting DISTINCT using setAggregate()), I had to get a little creative. I used setAggregate() to add the DISTINCT part to the JPQL query, but to set which fields are distinct, I build WHERE filters within a distinct filter (one where filter per field). The WHERE filters are set to look for anything that isn't null so it'll pick up the data. The data returned from the JPQL query has all the attributes of an entity so the fields and data specified in the distinct filter are picked out and returned in the response. Having done identical requests on both backends, this seems to return exactly the same data, in the same format.

Within common/icat/helpers.py, I've moved construct_icat_query() and execute_icat_query() into its own class as it seems to make sense to do so. I made this change largely because I added a function called check_attribute_name_for_distinct() which is only used in execute_icat_query() so it seemed to make sense to move all 3 functions into their own class. Thinking about it now, I wonder if the icat_query class should go in its own file, any thoughts?

There's also a bug fix for the WHERE filter - this is explained within the commit 2aea37c.

[MRichards99]

Fixed merge conflict for this PR.

[MRichards99]

In my description regarding this PR, I questioned whether the icat_query class should be in its own file or not. Since working on the include filter, I decided this would be a good idea to move it out (because the class was getting a bit long and was starting to clog up common/icat/helpers.py) and rename the class to ICATQuery too. These changes have been pushed to this branch, as per: 4f84e52

[MRichards99]

Changed base branch due to merging limit/skip filters into the where filter branch

[louise-davies]

If I try to add a where filter to a field which has been specified to be distinct, I get "No results found". This would be required to filter the Diamond Proposal table, which uses distinct filters to get investigation names & titles and you can filter on names and titles as well.

e.g. the following request does not work:

http://localhost:500-/investigations?distinct=["name", "title"]&where={"title": {"like": "dog"}}

[MRichards99]

@louise-davies:
Having had a play in a test Python ICAT script I have, it seems like an issue with Python ICAT. The like operator seems a lot more strict than it does in the DB backend. For example if I have a play with names that have the value of INVESTIGATION 1:

http://{{datagateway-api}}/investigations?where={"name": {"like":"INVESTIGATION 1"}} - this returns 1 result of my test data, as I'd expect
http://{{datagateway-api}}/investigations?where={"name": {"like":"INVESTIGATION"}} - this returns a 404 with "no results found".

You'd have thought the second one is 'like' the piece of data I'm after (i.e. INVESTIGATION 1) and would therefore return some results, but that doesn't seem to be happening.

As for the overarching feature required for Diamond, I do believe this works:
http://{{datagateway-api}}/investigations?distinct=["name", "title"]&where={"name": {"eq":"INVESTIGATION 1"}} - this returns the following which is correct for the test data I have:

[
    {
        "title": "Pay thus factor economic out. Former act and college.\nNumber keep debate trouble box. Area collection quality change. National old focus.\nStrong fall you prepare.",
        "name": "INVESTIGATION 1"
    }
]

As described above, this seems to be a LIKE operator issue. Right now, I'm a little bit stumped about what to do (Python ICAT deals with the LIKE operator itself, I just parse the value from the request), but hopefully I can think of something for next week.

[louise-davies]

@MRichards99 - this might require adding % around all strings passed to the like operator - I know that this is what topcat does to do wildcard searches in it's queries so perhaps that is what is missing. e.g. using like: %dog% vs just like: dog

[MRichards99]

Just made the change and it seems to work! Have a go and see what you think :)