-
Notifications
You must be signed in to change notification settings - Fork 14
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
Add Configuration Object to Semantic Manifest #95
Conversation
project_configuration: | ||
dsi_package_version: 1.2.3 | ||
time_spine_table_configurations: | ||
- location: example_schema.example_table |
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.
{{project_schema}}.mf_time_spine
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.
Looking good
@@ -23,5 +24,10 @@ def metrics(self) -> Sequence[Metric]: # noqa: D | |||
def interfaces_version(self) -> str: # noqa: D |
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.
Is this now duplicate information? Should we remove this property in favor of dsi_package_version
in project_configurations
?
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.
More thoughts came to me after my initial review. We should never be expecting the user to to set the dsi_package_version
. Thus we shouldn't be including it in the json schema spec. We should use a pydantic validator on the PydanticSemanticVersion
implementation which parses it if a value is provided, otherwise it should populate the the current package version. The former change indicates to users that it isn't something they should directly set. The latter change allows for delineation between deserialization and new object instantiation.
"$id": "project_configuration", | ||
"type": "object", | ||
"properties": { | ||
"dsi_package_version": {"type": "string"}, |
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 don't think we want the user the be able to specify the dsi_package_version
. This is something that should be auto-generated from the implementation classes. See the validator
that sets the interfaces_version
on the SemanticManifest
pydantic implementation
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.
Can you clarify how that would work? e.g. we release DSI v0.2, but the customer wrote and committed configs based on DSI v0.1. If the server is upgraded and deserializes the files, wouldn't the version be incorrect?
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.
Deserialization and parsing logic is not the same. The JSON schema is only used for validating the yaml prior to parsing it to the object. Specifically it is invoked in the from of <object_validator>.validate(...)
(example). Deserialization is the act of calling <object_type>.parse_raw(...yaml...)
deserialization by itself doesn't call json schema validation. Additionally in our json schema we explicitly disallow extra keys thus if someone tries to set a dsi_package_version
we want things to fail. Because deserialization doesn't do json schema validation, this is not a problem. Thus by using using a pydantic validate
setter we can handle both situtiations. When going through parsing, the dsi_package_version
should be None
, so we auto generate it. When deserializing, the value for dsi_package_version
would be included in the serialization and thus will be used.
"""Parses a MetricInputMeasure from a string (name only) or object (struct spec) input. | ||
|
||
For user input cases, the original YAML spec for a PydanticMetric included measure(s) specified as string names | ||
or lists of string names. As such, configs pre-dating the addition of this model type will only provide the | ||
base name for this object. | ||
""" |
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 doc string need some updating
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.
Updated.
if isinstance(input, str): | ||
input_split = input.split(".") | ||
if len(input_split) not in (2, 3): | ||
raise ValueError(f"Expected version string to be of the form x.y or x.y.z but got {input}") | ||
return PydanticSemanticVersion( | ||
major_version=input_split[0], | ||
minor_version=input_split[1], | ||
patch_version=input_split[2] if len(input_split) == 3 else None, | ||
) | ||
else: | ||
raise ValueError( | ||
f"{cls.__name__} inputs from YAML files are expected to be of either type string or " | ||
f"object (key/value pairs), but got type {type(input)} with value: {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.
We probably want to update this to be a validator similar to
dbt-semantic-interfaces/dbt_semantic_interfaces/implementations/semantic_manifest.py
Line 26 in 739fae8
def __create_default_interfaces_version(cls, value: str) -> str: # type: ignore[misc] |
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.
A little unclear how the validator would work in the case with the custom parser. Mind elaborating?
db47347
to
333469e
Compare
333469e
to
22218c8
Compare
@QMalcolm - updated as per comments. |
NVM, left out something. |
22218c8
to
5b3f00d
Compare
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.
Looks great! Thank you so much for all the work! I know we had to go back and forth on a few things, but it worked out great 🙂
Resolves #94
Description
Please see the linked issue.
Checklist
changie new
to create a changelog entry