-
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 meta to measures, entities, and dimensions #358
Add meta to measures, entities, and dimensions #358
Conversation
e155c0d
to
f6fea48
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 good! Left one main point of feedback.
Would love to also get @WilliamDee 's eyes on this just in case because I'm not super familiar with how meta
& config
are supposed to look.
Also - whenever we make a schema change, we get the core team's approval first. I'm not sure if that's necessary here since it's just copying what exists on a metric already, but I would recommend asking Jordan to confirm if we should get their eyes on this before merging.
@@ -37,6 +42,16 @@ class PydanticDimensionTypeParams(HashableBaseModel): | |||
validity_params: Optional[PydanticDimensionValidityParams] = None | |||
|
|||
|
|||
class PydanticDimensionConfig(HashableBaseModel, ProtocolHint[DimensionConfig]): |
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.
If these protocols & implementations are all exactly the same structure, I think we should just use the MetricConfig
protocol & implementation for all of them. Would be nice to remove the duplicate code if it's not needed. @WilliamDee would you foresee any problems with that?
It would be great if we could rename the class to just something more generic like SemanticLayerElementConfig
or something if we're going to use it on all these elements. That would technically be a breaking change for DSI, but I just checked in dbt-core and it's not used anywhere. So it should be fine.
We would want to bump DSI to the next minor version if we do that. So if we do that, I can walk you through the steps for that.
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 could do that, but a foreseeable issue comes when or if the Config ever diverges for different elements. Then in that case it may be abit of a pain in the ass to 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.
actually, seems like core just uses config
as some arbitrary dict, https://github.com/dbt-labs/dbt-core/blob/main/core/dbt/contracts/graph/unparsed.py#L615 so i think it's fine to generalize it in DSI
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.
Okay, I made this update for the resources in this PR. I will make a follow-up PR to consolidate the other resources. I will wait on Grace's approval to merge this PR.
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 all looks good to me! Just need to resolve the Courtney's comment of whether we want to consolidate the Config to a single class
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.
Requested one more change!
Also, do you mind searching dbt-mantle for the |
@DevonFulcher I also didn't realize we had |
@courtneyholcomb Based on my search, it looks like mantle and core have classes with the same name as |
@DevonFulcher Sounds like we're good then!! And yeah, sorry, I didn't put this in the appropriate PR 😆 |
def _implements_protocol(self) -> SemanticLayerElementConfig: # noqa: D | ||
return self | ||
|
||
meta: Dict[str, Any] = Field(default_factory=dict) |
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.
Would this work if we add more fields to the config and wanted to treat meta as optional? (For example, if we wanted to allow someone to add either some metadata or a tag.)
(This is not necessarily a blocking question.)
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.
Good point! We can make this optional in the future, though, without a breaking 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.
Is this not already optional? In a sense that, it'll default to an empty dict if you didn't provide it anything
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.
Ya, it is effectively optional because of the default, although not type Optional
.
### Description This PR addresses [this](#358 (comment)) feedback to consolidate the meta config into central models. This is technically a breaking change because some classes have been deleted, but Courtney confirmed that these classes are not being used by dbt-core. ### Checklist - [x] I have read [the contributing guide](https://github.com/dbt-labs/dbt-semantic-interfaces/blob/main/CONTRIBUTING.md) and understand what's expected of me - [x] I have signed the [CLA](https://docs.getdbt.com/docs/contributor-license-agreements) - [x] This PR includes tests, or tests are not required/relevant for this PR - [x] I have run `changie new` to [create a changelog entry](https://github.com/dbt-labs/dbt-semantic-interfaces/blob/main/CONTRIBUTING.md#adding-a-changelog-entry)
Description
This PR is modeled off of this prior PR. This PR adds meta to measures, entities, and dimensions.
Checklist
changie new
to create a changelog entry