OMERO.tables read() row specification is inconsistent

[spli]

For discussion?

stop=0 is currently treated as a special case, eg:

• read(start=0, stop=0) returns row 0
• read(start=i, stop=0) returns row i
• read(start=i, stop=i) returns no rows
• read(start=i, stop=i+n) returns rows[i..i+n-1]

The apparent intention is to replicate the underlying behaviour of PyTables? which uses stop=None to indicate one row should be returned. However, in OMERO.tables stop=0 is treated as stop=None which breaks the standard way of specifying Python ranges.

[spli]

See also #4000 and ​https://www.openmicroscopy.org/community/viewtopic.php?f=6&t=600

[jburel]

Moved from sprint 2012-12-18 (3)

[jburel]

Moved from sprint 2013-01-15 (4)

[jburel]

Moved from sprint 2013-02-12 (5)

[spli]

Does anyone have thoughts on this? The behaviour of stop=0 is inconsistent, both within OMERO.tables and with respect to the general Python range semantics (start..stop-1).

The options I can think of are:

• start=0,stop=0 returns all rows (should start>0,stop=0 return all rows beginning from start?)
• Treat as a Python range so start=0,stop=0 returns no rows

The current implementation corresponds to neither of these. Personally I prefer the latter in keeping with the Python range specifications (and C++ STL container iterators)

[jmoore]

This is largely the by-product of not being able to pass None via Ice without using an RLong. I'd have to check the git history, but I would have thought start=0,stop=0 should return all rows as a workaround for the passing of None. At some point, this may have been broken.

However, since it's broken at the moment, there's an opportunity to redefine it. I agree that proper Python semantics would be cleaner, but under what conditions do you think someone would pass start=0,stop=0 and want no rows?

[spli]

From #11478

Not sure where this should be handled, if at all, but passing stop=-1 to getWhereList effectively works as stop=numberofrows-1, making the search over the full dataset minus the last row.

[spli]

My current feeling is to aim for "no special cases" instead of something Python specific.

[spli]

From #12249

tables.addDataLength() -- sadly forgotten what this was intended for. Curtis?
read(..., BiggerThanSize?) shouldn't throw
read(null, ....) should return all columns

[jamoore]

Splitting 5.1.4 due to milestone decoupling

[jburel]

Discussed with Simon,moving to 5.2 (to be in synch with trello board)

[jburel]

Milestone OMERO-5.2.1 deleted

[jburel]

Milestone OMERO-5.2.2 deleted

[jamoore]

Referencing ticket #10084 has changed sprint.

[jamoore]

Referencing ticket #10084 has changed sprint.

[jburel]

Referencing ticket #9944 has changed sprint.

[jburel]

Referencing ticket #9944 has changed sprint.