Table query case insensitive

[will-moore]

See discussion at ome/omero-metadata#56 (comment)
Currently, we don't know whether an OMERO.table column will be named 'Image' or 'image'.
So we have to query for BOTH (in series, since parallel queries lead to table.close() race conditions).

As @sbesson suggested, this logic can be simplified if we handle case mismatches in column names.
In this PR, if you query a table for Image, Roi, Plate or Well and the table doesn't have a matching
column name but does contain the column name in lower case, e.g. image, then we
simply use the lower case for the query.

This means we don't need duplicate queries from the UI (see the JavaScript code is much simpler).

To test:

• See https://merge-ci.openmicroscopy.org/web/webclient/?show=project-857 (user-3)
• The most recent table on this Project (which is always picked for queries) has the Image column named 'image': https://merge-ci.openmicroscopy.org/web/webclient/omero_table/634804/
• Images named img-xx.png in that Project should display the Tables data correctly in the right-panel
• The URL https://merge-ci.openmicroscopy.org/web/webgateway/table/Project.datasetLinks.child.imageLinks.child/36638/query/?query=Image-36638 (using query Image-36638) should return results for the table, even though the column names in the JSON data will be "image".

[will-moore]

Re: ome/omero-metadata#56 (comment)
I could also support ?query=ROI-123 here, but the logic would be slightly different from the current logic:
if "ROI" is not in column_names, then check if "Roi" is in column_names, if not then check if "roi" is in column_names.
Since we don't query by ROI anywhere, this doesn't help simplify the code and rather makes the behaviour less predictable. E.g. if ROI is supported, then why not IMAGE?

We could also make queries case insensitive for ALL column names (not just Image, Well, Roi, Plate). This wouldn't hurt performance, but again, I would prefer if the ?query=... API is as close as possible to the underlying table query API.

[sbesson]

Tested the query API change using https://idr.openmicroscopy.org/webclient/omero_table/15780187 (idr0041) which is a reasonably large OMERO.table with the image column names. Using production IDR,

[sbesson@prod95-omeroreadonly-1 ~]$ time curl http://localhost/webclient/omero_table/15780187/?query=image-3431104
...
                <td><a target="_blank" href="/webclient/?show=image-3431104">3431104</a></td>
                
            
        </tr>
        
    </body>
</html>

real	0m0.158s
user	0m0.000s
sys	0m0.010s
[sbesson@prod95-omeroreadonly-1 ~]$ time curl http://localhost/webclient/omero_table/15780187/?query=Image-3431104
{"error": "Error executing query: (Image==3431104)"}
real	0m0.111s
user	0m0.004s
sys	0m0.006s

With this PR included in the pilot server

[sbesson@pilot-idr0072-omeroreadwrite ~]$ time curl http://localhost/webclient/omero_table/15780187/?query=image-3431104
...
                <td><a target="_blank" href="/webclient/?show=image-3431104">3431104</a></td>
                
            
        </tr>
        
    </body>
</html>

real	0m0.154s
user	0m0.003s
sys	0m0.007s
[sbesson@pilot-idr0072-omeroreadwrite ~]$ time curl http://localhost/webclient/omero_table/15780187/?query=image-3431104
...
                <td><a target="_blank" href="/webclient/?show=image-3431104">3431104</a></td>
                
            
        </tr>
        
    </body>
</html>

real	0m0.152s
user	0m0.006s
sys	0m0.007s

In terms of code changes, most of the logic happens during the translation of our <name>-<value> into a case sensitive <column_name>==<value> query so there should be minimal performance impact. This also greatly reduces the complexity of the table loading in metadata_general.html.

In terms of documentation, it might make sense to update the docstring of _table_query to capture the new contract for this specific query variant. Is there another reference documentation place that describes the expectation for ?query=<name>-<value>?
In terms of test coverage, I could imagine a handful of test additions to https://github.com/ome/openmicroscopy/blob/develop/components/tools/OmeroWeb/test/integration/test_table.py covering the various scenarios would be useful to catch potential regressions.

Generally, given the existing variations in the column names of OMERO.tables, having some API allowing to handle synonyms for some of the reserved columns while preserving the underlying case-sensitive query API is a good balance.

[sbesson]

If we wanted to handle all case-insensitive variations of these reserved column names, this could become

if c_name not in columns_names and c_name.lower() in ("image", "roi", "plate", "well") and c_name.lower() in column_names:

I don't know of a concrete use case for now so unless you feel strongly about it, happy to start with the variants for our own tools i.e. image/Image for now and adjust as new use cases arise.

[will-moore]

I think it's simpler to stick with image/Image instead of supporting all upper/lower case variants.

[will-moore]

To test last commit, you need to open the dev tools and check the Console when opening the Tables tab for an Image that doesn't have any Tables data. Shouldn't see any errors in the Console.

[sbesson]

Using a few variations of the image/Image column names. No error was reported in the console developer tools. Overall this is a good simplification of the code, centralizing the logic handling column name synonyms in the query internal function and removing various conditional blocks in the Javascript.