-
Notifications
You must be signed in to change notification settings - Fork 2
replace keywords with types and relax restrictions on keywords #43
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
Changes from 4 commits
ff305ec
9612185
f99e28c
218af84
f1db354
3e1f652
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,46 @@ | ||
| # Migrations are used to ensure that data provided by nodes that are using an | ||
| # older version of the schema are updated automatically to comply with the newest | ||
| # version of the schema. | ||
| # | ||
| # If a backwards incompatible change is introduced in the schema, please make a | ||
| # new migration function here to ensure that older data is properly updated. | ||
| # | ||
| # Migration functions will be applied to each node's data in the order that they | ||
| # appear in the MIGRATIONS variable at the bottom of this file. | ||
| # | ||
| # All migration function should take a single argument which contains the node's | ||
| # data and modify that data in place. | ||
|
|
||
| def convert_keywords_to_types(data: dict) -> None: | ||
| """ | ||
| Add service types if they don't exist. | ||
|
|
||
| Since version 1.3.0 service "types" are now required. If they don't exist | ||
| then they can be derived from service "keywords" which were used in place | ||
| of "types" prior to this version. | ||
| """ | ||
|
|
||
| keyword2type = { | ||
| "catalog": "catalog", | ||
| "data": "data", | ||
| "jupyterhub": "jupyterhub", | ||
| "other": "other", | ||
| "service-wps": "wps", | ||
| "service-wms": "wms", | ||
| "service-wfs": "wfs", | ||
| "service-wcs": "wcs", | ||
| "service-ogcapi_processes": "ogcapi_processes" | ||
| } | ||
| for service in data["services"]: | ||
| if "types" not in service: | ||
| service["types"] = [] | ||
| for keyword in service["keywords"]: | ||
| if (type_ := keyword2type.get(keyword)): | ||
| service["types"].append(type_) | ||
| if not service["types"]: | ||
| service["types"].append("other") | ||
|
|
||
|
|
||
| MIGRATIONS = ( | ||
| convert_keywords_to_types, | ||
| ) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we add the explicit |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,4 +2,4 @@ | |
| addopts = [ | ||
| "--import-mode=importlib", | ||
| ] | ||
| pythonpath = "." | ||
| pythonpath = "./marble_node_registry" | ||
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.
Should this migration be within a version mapping?
For example, migrating from 1.2->1.3 makes senses to apply this fix, but it shouldn't be done if 1.3 is already applied. Maybe future migration will require specific version checks as well.
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 was thinking about that but then I decided against it due to the complexity of tracking version differences within the schema.
If you'd prefer that strategy I can make it work but it didn't seem worth it at the time.
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'm fine with the current approach if it avoids unnecessary complexity/over-engineering since I don't expect the schemas to change too often. If they change drastically, it would probably be a major version anyway, and migration would not be possible if such change was actually needed.