-
Notifications
You must be signed in to change notification settings - Fork 9
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
DTS manifest file part 1 #205
base: develop
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's been so long I don't really remember how the mapping mechanism works
DTS_MANIFEST: ["json"], | ||
JSON: ["json"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DTS_MANIFEST and JSON are both the text JSON
and so collide in the map
Ugh, hit finish review too early. I'm not done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Holding the review here as I think the app configuration is incorrect
# Data Transfer Service Manifest format (which is a specific JSON format) | ||
DTS_MANIFEST = "JSON" | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These types are just the file types, regardless of the semantics of the type. Just JSON should be used here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
{ | ||
"id": "import_specification", | ||
"title": "Import Specification", | ||
"app_weight": 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is supposed to be autogenerated IIRC but I don't see any code changes that would cause this to be different
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC you need to update the mapping here:
file_format_to_app_mapping[JSON] = [escher_map_id] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well that'd be real cool if that were documented anywhere. I'll add that and fix it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some documentation to the README. Not perfect, but should be enough for now.
Ok, that was a very silly change I did.
|
Trivy's being whiny again: |
@@ -120,7 +129,7 @@ | |||
fba_model_id, | |||
import_specification, | |||
] | |||
file_format_to_app_mapping[JSON] = [escher_map_id] | |||
file_format_to_app_mapping[JSON] = [escher_map_id, import_specification] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now I'm wondering if we should have a separate type in the dropdown for DTS manifests vs. import specifications. Maybe just DTS manifest
? That would be forward compatible if we ever wanted to support standard import specifications with JSON input.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I thought of that. I guess that would be a trivial change, but I'm not sure the best thing to call it. I also wonder if it would be confusing to users at all? They'd have to read instructions on the whole DTS process anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I take it back, that's not trivial at all. It means a narrative change at minimum, possibly an API change if we want to be really thorough. Maybe a new API endpoint?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would make it a query param probably
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just checking here - you're saying the separate type and query param is the way you're going to go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, if it's going to work that way, there probably shouldn't be a JSON: dts_parser entry in the parser mapping
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is how it work right now, as of this PR, and everything else that's in it. A later PR that updates the endpoint to use a query param will probably undo this. Also, the Narrative will need to have a mapping of some sort, which is what this sets up. So it might not be from .json
-> Import Specification
, but it'll need to be something similar.
I don't want this to get more complicated and would like to keep that in a single PR with the bulk_specification
endpoint change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, as long as the plan is clear
Quality Gate passedIssues Measures |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM given the caveats re reworking this have have a specific DTS manifest type
@@ -0,0 +1,122 @@ | |||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem to match the documentation in individual_parsers but I assume the format is still changing
This includes the first steps toward having the DTS manifest files as import specifications. It does the following:
.json
to the allowed import spec files, asDTS_MANIFEST
DTS_MANIFEST
to a (for now) dummy parser function.Next PR will make the parser do some parsing.