Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In place import #1929

Closed
wants to merge 2 commits into from
Closed

In place import #1929

wants to merge 2 commits into from

Conversation

joshmoore
Copy link
Member

In combination with https://github.com/joshmoore/omero-user-scripts/blob/in-place-import/InPlaceImport.py, this PR allows for in-place imports. There are several further changes that may should happen to that script:

Once these are complete, it may should be moved into the http://github.com/ome/scripts repository.

Dry runs

By default, execution simulates bin/omero import -f and lists which files would be imported. This allows the detection of directories with multiple filesets.

Testing

  • git clone https://github.com/joshmoore/omero-user-scripts.git lib/scripts/josh
  • bin/omero script list
  • bin/omero script launch /josh/InPlaceImport.py Path=/home/data/sample/leica-lif/Beta Catenin.lif Dry_Run=False

Expected linkage

/OMERO/ManagedRepository/root_0/2013-12/19/20-42-18.901/data/sample/leica-lif$ ls -ltra
lrwxrwxrwx 1 jamoore jamoore   44 Dec 19 20:42 Beta Catenin.lif -> /home/data/sample/leica-lif/Beta\ Catenin.lif
...

Web example

screenshot from 2013-12-19 20 53 19

screenshot from 2013-12-19 21 08 15

In order to be able to find the right location to symlink
the file, it's necessary to find the originalfile object
for upload *before* verifyUpload() has been called.
joshmoore added a commit to joshmoore/omero-user-scripts that referenced this pull request Dec 19, 2013
Requires ome/openmicroscopy#1929 for the
`RawFileStore.getFileId` method.
@ximenesuk
Copy link
Contributor

This all works as expected both from the cli and through the web. One question though, why is more of the path used here? ie a normal import will give me a repo path of:

root_0/2014-01/01/14-08-46.811/IAGFP-Noc01_R3D.dv
root_0/2014-01/01/14-08-46.811/IAGFP-Noc01_R3D.dv.log

while an in-place import results in:

root_0/2014-01/01/14-01-06.863/Work/Images/dv/IAGFP-Noc01_R3D.dv
root_0/2014-01/01/14-01-06.863/Work/Images/dv/IAGFP-Noc01_R3D.dv.log

@joshmoore
Copy link
Member Author

@ximenesuk : the difference is almost certainly the Python vs. the Java implementation. In thinking over this, I'm wondering if it wouldn't make more sense to teach CommandLineImporter how to do the symlink-ing so that the two implementations would be identical (no need for all the "TBDs")

@mtbc
Copy link
Member

mtbc commented Jan 6, 2014

The "normal" import has ManagedRepositoryI.trimPaths utilizing FormatReader.getRequiredDirectories, falling back to retaining three parents if there is no help from Bio-Formats.

@joshmoore
Copy link
Member Author

Thanks for the initial review, all. I'm closing this PR since it was mostly for discussion and investigation. I'll open a PR with these changes on dev_5_0 though so a proper in-place import PR can be built on top of it.

@joshmoore
Copy link
Member Author

Marked off some of the TODOs since gh-1989 supports them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants