Task #10703 (closed)
Support pre-FS original_metadata.txt
Reported by: | jamoore | Owned by: | mtbcarroll |
---|---|---|---|
Priority: | blocker | Milestone: | 5.0.0-rc1 |
Component: | API | Version: | 5.0.0-beta1 |
Keywords: | n.a. | Cc: | fs@… |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | 0.0d |
Sprint: | OMERO 5 Beta 2 (1) |
Description
See #10349
The implementation of the OriginalMetadataRequest? currently silently ignores pre-FS data, since there is not yet a database upgrade for properly testing that part of the scenario. Post-demo 3, the implementation for parsing the INI-like file should be added to handle the file annotations of the form:
[GlobalMetadata] IlluminationChannel #2 Acquire=true IlluminationChannel #1 Acquire=true DataChannel #3 Acquire=true DataChannel #1 Acquire=true ... [SeriesMetadata] Track #3 Sampling Method=1 DetectionChannel #1 SPI Wavelength Start=415.0 Track #3 Bleach Scan Number=0 ...
At the same time, the OriginalMetadataRequestTest? should be reviewed, since getting it working during demo 3 was also difficult. (Note: it might be necessary to re-add the generation of the original_metadata.txt file to the code base, even if just under test/, since it was removed from OMEROMetadataStoreClient on develop).
Change History (21)
comment:1 Changed 11 years ago by jmoore <josh@…>
comment:2 Changed 11 years ago by jburel
Client might have to put the code back to handle pre-FS data.
This has to be decided soon
comment:3 Changed 11 years ago by jburel
- Sprint FS demo 4.x deleted
Moving out of Demo 4.x since we will not handle a mix of data for now
comment:4 Changed 11 years ago by jamoore
- Milestone changed from OMERO-5 to 5.0.0-beta2
- Owner set to mtbcarroll
- Priority changed from minor to blocker
- Version set to 5.0.0-beta1
Mark, would you be ok to look at this ASAP? (i.e. before other DB changes)
comment:5 Changed 11 years ago by jamoore
- Sprint set to OMERO 5 Beta 2 (1)
comment:6 Changed 11 years ago by mtbcarroll
Looks like the FS version comes out with a Hashtable<String, Object> for each of global and series. OriginalMetadataRequestI.loadFileAnnotation gets a file annotation ID but how to parse the corresponding INI-style file into such I've yet to determine; for instance, given the String table key, do we thus already know which datatype we expect after the "=" for filling in the Object value, so we can tell a false Boolean from a "false" String? And, how to fit the INI "[…]" section names into this? No doubt it'll all become clear next week.
comment:7 Changed 11 years ago by mtbcarroll
- Status changed from new to accepted
comment:8 Changed 11 years ago by mtbcarroll
Oh, it looks like the [Global metadata] or [Series metadata] INI section names are about deciding on global or series, makes sense.
comment:9 Changed 11 years ago by mtbcarroll
Apparently the Map<String, RType> maps may always receive RString values.
Given how INI-like the format looks, probably best to parse it as exactly INI.
comment:10 Changed 11 years ago by mtbcarroll
Okay, so the description has [GlobalMetadata], OriginalMetadataRequestI has [Global metadata], webclient/views.py has [Global Metadata]. If I try downloading from howe I get [GlobalMetadata].
comment:11 Changed 11 years ago by jamoore
I would vote for using the value from the pre-FS property files across the board. Melissa, Jean-Marie, Will?
comment:12 Changed 11 years ago by wmoore
OK - let me know if you need any changes in web etc.
comment:13 Changed 11 years ago by jburel
Yes, same value.
comment:14 Changed 11 years ago by mtbcarroll
From OriginalMetadataRequestI I wonder what the easiest way is to get access to AbstractFileSystem.getFilesPath so that it can actually read the original metadata.
comment:15 Changed 11 years ago by jamoore
You'll need to also inject the OriginalFilesService along with the PixelsService.
comment:16 Changed 11 years ago by mtbcarroll
- Resolution set to fixed
- Status changed from accepted to closed
Fixed by https://github.com/openmicroscopy/openmicroscopy/pull/1717.
(I'm not sure what's going on with that test class, but after some poking it looks like quite a separate effort.)
comment:17 Changed 11 years ago by jamoore
Which test class?
comment:18 Changed 11 years ago by mtbcarroll
OriginalMetadataRequestTest
comment:19 Changed 11 years ago by jamoore
If you mean how it works, happy to discuss. If you mean how it is supposed to have OMERO4 data present, that's a big(gish) issue. Most likely we'll have to have MockFactories for producing both types.
comment:20 Changed 11 years ago by mtbcarroll
Well, it doesn't seem to work right now. (-: For attaching OMERO4 data, I guess that we need a general test framework capability to get non-FS data into an FS server (I don't know to what extent that is more than just "not in a fileset"), after that it's just a matter of attaching a file annotation that's in the right namespace. Probably worth some kind of a ticket anyway, or adding to an existing one.
comment:21 Changed 11 years ago by Josh Moore <josh@…>
- Remaining Time set to 0
(In [a6df36dc09a77cbe8c336559585372285fb1f309/ome.git] on branch develop) Merge pull request #1717 from mtbc/trac-10703-original-metadata
fix #10703: download pre-FS original metadata in FS
(In [ccf7b8b1ef871d54febb5f04dd696c9d25348937/ome.git] on branch develop) Outline for handling pre-FS data (See #10703)