Tables new API#5481
Conversation
In order to support old and new PyTables versions, this allows for choosing during service creation the storage provider. This is the first step in to allowing non-HDF backends.
efc284b to
ca48b52
Compare
|
Will that also be available in the Java |
@dominikl : no, these are only backend changes.
The methods weren't really added, only refactored from elsewhere. Their function is to maintain a counter of how often the file itself was opened, as opposed to column management. In general, PyTables doesn't easily provide column addition/removal. It requires recreating the file. |
|
|
$ pip freeze | grep tables
tables==3.3.0With Java integration tests on a Debian 9 system I am having some trouble with |
|
Thanks, @mtbc. Things I see:
|
|
Yes, if I upgrade to 3.4.2 then the |
|
(It's a pity that even Debian unstable is on tables 3.3.0 but I need to fiddle versions of other things anyway because Debian 9's packaged django stuff is too new for web.) |
|
what are the issues with Django? Probably worth a card |
|
I don't know but have now created https://trello.com/c/GN2e5t9C/245-omeroweb-with-newer-django. |
|
Comment added to card |
|
Taking a look at this, I've some confusion in that there are also |
|
I have removed the exclude label. |
TablesI now retries to acquire access to the related repository. omero.tables.RETRIES, by default 20, is used if not argument is passed to the constructor. Tests have been updated to perform no retries. See: https://trello.com/c/wPBnTfPU/58-flaky-tests
1ec5bc0 to
1eb824a
Compare
Usages of the two camel-cased methods were spread over hdfstoragev2 and columns. Splitting columns.py into 2 files as with the storage is both less useful (since no extension point is needed) and more disruptive since the file is already imported elsewhere. Instead, the few uses of camel-case have been wrapped with a check for the new version of PyTables and where necessary, the underscore version is used.
1eb824a to
bb8a484
Compare
|
I added a comment while working on doc |
Earlier issue now fixed. 👍 |
|
Did you install tables from pypi? |
|
I installed with |
|
The |
|
in this the case we will have to indicate that 3.3 is not working in the doc. This will require also an ome-install PR so it can be reflected in the installation doc |
|
Yes, to confirm, |
|
omero-install PR ome/omero-install#169 |
|
doc PR ome/omero-documentation#1771 |
|
i will check the tests tomorrow but it seems that it will be good to merge |
|
No table failure |
This adds on to 1264642 (omegh-5481) but not just adding a wait to the .omero/repository lookup but as well to the .omero/repository/*/repo_uuid lookup, so that the 20 REPEATS don't progress within 2-3 seconds but instead take long enough for the integration server has time to configure itself
Adapts @joshmoore's metadata53 code while accommodating ome#5481
What this PR does
Deprecate usage of the old PyTables API
Table creation and manipulation tested with the following version of pytables:
Testing this PR
check that the integration tests and training examples are green
Related reading
--depends-on #5409