Fix HdfStorage.read() implementation to work with all column types

[sbesson]

Reported by @jburel, the tables.read() method internally uses col.values (via _getrows). For any column type with overrides the default methods of AbstractColumn like MaskColumnI, this will fail.

fe8b863 tried to address the problem by using the getsize() API which should be independent of the column implementation details. However, testMaskColumn is still failing as the logic does not populate the .bytes attributes.

6c27eae is a more robust fix to the underlying issue which uses the fact that the column API effectively has a read method and effectively delegates to this API like readCoordinates.

All the other commits expand the unit tests to cover both readCoordinates and read scenarios for the different column types (long, string, mask) as well as a test for various arguments of table.read

Proposing for a patch release of omero-py

[snoopycrimecop]

Conflicting PR. Removed from build OMERO-python-superbuild-push#707. See the console output for more details.
Possible conflicts:

• PR Add logic to search OMERO.tables on non Pythonic named columns #287 sbesson 'Add logic to search OMERO.tables on non Pythonic named columns'
  • test/unit/tablestest/test_hdfstorage.py

--conflicts Conflict resolved in build OMERO-python-superbuild-push#708. See the console output for more details.

[joshmoore]

One minor item I noticed which we might want to just consider later, otherwise 👍

[joshmoore]

The only thing I'd have to check is if there are any situations where the single read is significantly faster, though I assume it's a time v. space issue.

[sbesson]

I certainly see how the performance can vary depending of the ratio percentage_of_read_columns/percentage_of_read_rows.

I would assume readCoordinates will suffer from the same tradeoffs as it it also looping over the individual columns to extract records and combine them into a grid.

[sbesson]

Objections to capture this as an issue and merging?

[joshmoore]

WFM