Task #12781 (accepted)
Opened 10 years ago
Last modified 5 years ago
Bug: CLI import to a dataset in a different group to current fails.
Reported by: | cblackburn | Owned by: | cblackburn |
---|---|---|---|
Priority: | critical | Milestone: | FacilityManagers |
Component: | Import | Version: | 5.1.0-m1 |
Keywords: | n.a. | Cc: | server@… |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | n.a. |
Sprint: | n.a. |
Description (last modified by cblackburn)
Using a local build of origin/develop with a user having datasets in several different groups, a targeted import fails if the target dataset is not in the current group. See console output in first comment.
Change History (20)
comment:1 Changed 10 years ago by cblackburn
comment:2 Changed 10 years ago by cblackburn
- Summary changed from Bug: CLI import to a dataset in a different group to default fails. to Bug: CLI import to a dataset in a different group to current fails.
comment:3 Changed 10 years ago by sbesson
- Owner set to sbesson
- Status changed from new to accepted
comment:4 Changed 10 years ago by mtbcarroll
- Cc mtbcarroll added
I had a bit of a look at this and couldn't figure it out. If early in the CommandLineImporter constructor I do store.setCurrentGroup to the dataset's group, the fileset and image are still created with the other group instead; perhaps they're created beforehand or quite separately.
comment:5 Changed 10 years ago by sbesson
Agreed, https://github.com/openmicroscopy/openmicroscopy/blob/v5.1.0-m4/components/blitz/src/ome/formats/OMEROMetadataStoreClient.java#L1958 contains the logic to switch group in the store when looking for the target across groups. However, looking at the import log logging the store used server-side uses the initial context.
Interestingly a related bug is that the following also launches a stack trace.
bin/omero import test.fake -d 0
My proposal here is to unify the CLI behavior with the one of Insight, i.e. force the correct context to be used in the initial command. That would likely mean trying to retrieve the dataset/screen at the CLI import level and returning a meaningful error message early.
comment:6 Changed 10 years ago by cblackburn
My reason for discovering this bug was attempting to use the OMEROMetadataStoreClient to switch groups following the resolution of a templated path. I was trying to push that resolution away from the CLI importer. Having the CLI importer resolve which group the dataset in in would seem to go away from that. Since there is/was a mechanism for switching groups in the OMEROMetadataStoreClient is it worth understanding why that fails before moving a fix down to the CLI?
comment:7 Changed 10 years ago by cblackburn
Hmm, is this because of FS? As the fileset is created at upload using the logged-in group that creates the problem when the import accesses a fileset that may not be available to it? has anyone tested this on a 4.4 server? If this is the case then maybe Sebastien's solution is the obvious one - or chgrping the fileset prior to import?
comment:8 Changed 10 years ago by mtbcarroll
Do you happen to know what code creates the fileset and image? I tried a really rather early client-side setCurrentGroup but even that perhaps wasn't early enough.
comment:9 Changed 10 years ago by cblackburn
So, trying to import into a Dataset in a read-only group while logging in to the default private group:
omero import -d 51 ~/Work/Images/dv/CFPNEAT01_R3D.dv
results in
omero-latest=> select * from fileset where owner_id=2; id | permissions | templateprefix | version | creation_id | external_id | group_id | owner_id | update_id ----+-------------+-----------------------------------+---------+-------------+-------------+----------+----------+----------- 1 | -120 | user-0_2/2015-03/19/10-05-55.279/ | | 50 | | 3 | 2 | 50 2 | -120 | user-0_2/2015-03/19/10-08-32.408/ | | 83 | | 3 | 2 | 83 3 | -120 | user-0_2/2015-03/19/10-08-58.359/ | | 114 | | 3 | 2 | 114 4 | -120 | user-0_2/2015-03/19/10-09-26.858/ | | 146 | | 3 | 2 | 146 51 | -120 | user-0_2/2015-03/19/14-37-25.655/ | | 792 | | 3 | 2 | 792 (5 rows) omero-latest=> select * from dataset where owner_id=2; id | description | permissions | name | version | creation_id | external_id | group_id | owner_id | update_id ----+-------------+-------------+--------------+---------+-------------+-------------+----------+----------+----------- 51 | | -56 | rog-data | | 780 | | 4 | 2 | 780 4 | | -120 | nochecksum | | 38 | | 3 | 2 | 38 3 | | -120 | nominmax | | 37 | | 3 | 2 | 37 2 | | -120 | nothumbnails | | 36 | | 3 | 2 | 36 1 | | -120 | standard | | 35 | | 3 | 2 | 35 (5 rows)
Here the relevant Fileset is id=51. It is create in the context of the private group, not the read-only group. So, as in the log in the first comment, the group is logged as being changed but that context isn't then being used beyond that point.
comment:10 Changed 10 years ago by cblackburn
- Milestone changed from 5.1.0 to 5.1.1
- Owner changed from sbesson to cblackburn
- Priority changed from blocker to critical
Although originally marked as a blocker, there are work-arounds to this such as: using Insight, switching groups before importing to a target in that group or importing and then moving between groups post-import. Given these work-arounds and the imminency of 5.1.0 I'd suggest downgrading and pushing this so as not to hold up that release.
comment:11 Changed 10 years ago by cblackburn
See https://trac.openmicroscopy.org/ome/changeset/2f5cf9b793f3afabf0afc6b234ff82c67dd76387/ome.git where a relevant test, test_cliimport::testTargetInDifferentGroup was marked as xfail due to this bug. (now marked as broken but a sufficient test for this issue.)
comment:12 Changed 10 years ago by cblackburn
https://github.com/openmicroscopy/openmicroscopy/pull/3658 mitigates the effect of this bug preventing the unnecessary uploading of files if the Dataset is inaccessible and providing some more helpful feedback.
comment:13 Changed 9 years ago by cblackburn
- Milestone changed from 5.1.1 to 5.1.2
comment:14 Changed 9 years ago by jamoore
- Milestone changed from 5.1.4 to OMERO-5.1.4
Splitting 5.1.4 due to milestone decoupling
comment:15 Changed 9 years ago by cblackburn
- Description modified (diff)
- Milestone changed from OMERO-5.1.4 to OMERO-5.2.0
A tentative work around was tried at https://github.com/openmicroscopy/openmicroscopy/pull/4169 but is not suitable as a more general solution.
comment:16 Changed 9 years ago by cblackburn
- Description modified (diff)
Pushing to 5.2 unless a 5.1.5 is mooted.
comment:17 Changed 9 years ago by jburel
- Milestone changed from OMERO-5.2.1 to OMERO-5.2.2
Milestone OMERO-5.2.1 deleted
comment:18 Changed 9 years ago by jburel
- Milestone changed from OMERO-5.2.2 to OMERO-5.2.1
Milestone OMERO-5.2.2 deleted
comment:19 Changed 9 years ago by jburel
- Milestone changed from OMERO-5.2.2 to FacilityManagers
comment:20 Changed 5 years ago by mtbcarroll
- Cc server@… added; mtbcarroll removed
May also be at the root of https://www.openmicroscopy.org/community/viewtopic.php?t=8724&p=20801.