Task #4000 (closed)
Bug: table.read() invocation returns nothing with subcalls
Reported by: | jamoore | Owned by: | szwells |
---|---|---|---|
Priority: | minor | Milestone: | OMERO-4.4 |
Component: | Services | Version: | n.a. |
Keywords: | n.a. | Cc: | sylittlewood, szwells |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | 0.0d |
Sprint: | 2012-01-31 (7) |
Description (last modified by jmoore)
table.read when called with method calls:
table.read(range(len(table.getHeaders())), ...
returns nothing.
See https://www.openmicroscopy.org/community/viewtopic.php?f=6&t=600
Change History (12)
comment:1 Changed 13 years ago by jmoore
- Description modified (diff)
comment:2 Changed 12 years ago by jmoore
- Cc sylittlewood szwells added
- Component changed from General to Services
- Milestone changed from Unscheduled to OMERO-Beta4.4
comment:3 Changed 12 years ago by szwells
This looks to be a mismatch between the use of zero in the call to read and the expectation of None in the PyTables? API,
e.g. From the PyTables? API: "If you do not specify neither start nor stop, then all the rows in the table are selected"
where the defaults are None rather than zero.
If Ice is changing the value to zero then that might be why no rows are returned.
Possible Resolutions:
- Fix the code so that if Ice passes through 0,0 in the argument then they are converted back to None, None in the call to PyTables?
- Fix the documentation so that using 0,0 doesn't return all rows. Note that coders can use a call to getNumberOfRows() to retrieve the number of rows in the table and pass that as the third argument to read().
comment:4 Changed 12 years ago by szwells
- Owner set to szwells
- Status changed from new to accepted
comment:5 Changed 12 years ago by szwells
I have a fix for this which is basically inserting the following:
if start == 0 and stop == 0: stop = self.getNumberOfRows()
into the TableI.read() method just before the try block. This forces the read method to return everything when it is called using the the expected PyTables? API behaviour. I can't see any unintended consequences of taking this approach at the moment but welcome any comments.
comment:6 Changed 12 years ago by jmoore
Simon: Would it not be sufficient to use None rather than querying the file about the number of rows?
Also: have you pushed this anywhere? If not, I can put it on a sprint5-bugs branch/PR if you can get it to me.
comment:7 Changed 12 years ago by szwells
- Sprint set to 2012-01-17 (6)
comment:8 Changed 12 years ago by szwells
only just saw your comment Josh. I tried using None but it didn't work. Perhaps I don't have all of the Ice voodoo mastered yet. As a partial fix this at least brings our tables developer API into line with that of PyTables?.
I can then push this to my github ready for a PR...
comment:9 Changed 12 years ago by jmoore
Simon, do push it up somewhere and we'll try to get it in ASAP.
comment:10 Changed 12 years ago by jburel
- Sprint changed from 2012-01-17 (6) to 2012-01-31 (7)
Moved from sprint 2012-01-17 (6)
comment:11 Changed 12 years ago by jmoore
- Resolution set to fixed
- Status changed from accepted to closed
Cherry-picked Simon's commit and added a passing test. I changed stop = self.getNumberOfRows() to stop = None since they are the same in the PyTables API. To test, rerun the tablestest.service test:
ant test -DTEST=tablestest.service
inside of the OmeroPy directory.
Pushed to my sprint7-server-backlog branch.
comment:12 Changed 12 years ago by jmoore <josh@…>
- Remaining Time set to 0
(In [d7b55bb116e581e055491845536aa7a130289b0b/ome.git] on branch develop) Passing test and simplification (Fix #4000)
Elwood/Simon?: this should be a pretty straight-forward matter of testing and checking the PyTables? API usage if either of you would like to look into it.