ome / openmicroscopy

OME (Open Microscopy Environment) develops open-source software and data format standards for the storage and manipulation of biological light microscopy data. A joint project between universities, research establishments and industry in Europe and the USA, OME has over 20 active researchers with strong links to the microscopy community. Funded by private and public research grants, OME has been a major force on the international microscopy stage since 2000.

https://www.openmicroscopy.org/omero

GNU General Public License v2.0

200 stars 102 forks source link

Check query without matches #6411

Open knabar opened 2 months ago

knabar commented 2 months ago

What this PR does

Adding a test to verify the behavior of the bitmask table query API call when a query is given that does not match any rows in the table.

will-moore commented 2 months ago

It looks like this test is failing at https://merge-ci.openmicroscopy.org/jenkins/job/OMERO-test-integration/lastCompletedBuild/testReport/OmeroWeb.test.integration.test_table/TestOmeroTables/test_table_bitmask_query_result4_/

knabar commented 2 months ago

@chris-allan While looking into a bug we first thought to be in Pageant, @kyleBalisWest and I tracked down this issue in the bitmask API call. If there are no matches, all rows are returned as matching. I think the issue is that if slice is called without any rows, it returns everything.

With the coming updates I don't think the bitmask call is used anymore in any of our projects.

chris-allan commented 2 months ago

Just did a little sleuthing to realize that this is a regression coming from ome/omero-web#554. Previously, when no "hits" were found even though a slice was being performed no paging would take place so the rows returned from perform_table_query() would have been empty.

chris-allan commented 2 months ago

Also, this read everything when the indexes are empty behavior is also not consistent with PyTables itself but rather "special" as it relates to the omero.column implementations. Specifically, omero.column.AbstractColumn.readCoordinates().

@sbesson: Once we've settled on the test cases here we should update the OMERO.tables documentation so this is clear; neither read() or readCoordinates() behave like this.