-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Move replace_attributes, merge_attributes onto AssetSpec, publicise #25941
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
5d7fb8c
to
e1756ba
Compare
e1756ba
to
5f4b4a9
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.
generally supportive, just want to be careful about old params
skippable: bool = ..., | ||
group_name: Optional[str] = ..., | ||
code_version: Optional[str] = ..., | ||
freshness_policy: Optional[FreshnessPolicy] = ..., |
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 we remove freshness_policy to avoid needing to go through a deprecation cycle ?
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.
You just mean freshness_policy
, right? or are we removing automation_condition too 👀
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.
lol yeah
Having a method makes sense. My only question before we introduce this is how we handle specs and |
I can think of a couple options:
my_specs_and_defs = ...
my_updated_specs_and_defs = [
asset.replace_spec_attributes(owner="ben@dagsterlabs.com")
for asset in my_specs_and_defs
]
my_specs_and_defs = ...
my_updated_specs_and_defs = [
dg.replace_spec_attributes(asset, owner="ben@dagsterlabs.com")
for asset in my_specs_and_defs
]
# Can still call directly on specs
my_spec = ...
my_spec = my_spec.replace_attributes(...)
my_specs_and_defs = ...
my_updated_specs_and_defs = [
asset.replace_attributes(owner="ben@dagsterlabs.com")
for asset in my_specs_and_defs
if isinstance(asset, AssetSpec)
else
asset.map_specs(lambda spec: spec.replace_attributes(owner="ben@dagsterlabs.com")
] |
@benpankow wrt unifying behavior around assetsdefinition and assetspec |
That's true - I do think the predicate case will be much less common in the mixed spec/definitions case, e.g. if you're conditionally changing properties, it's probably right after pulling in specs from an integration, since at that point you have a relatively homogenous set of specs where you can reason about what metadata you're predicating on. That being said, maybe we want something like def map_specs(func: Callable[[AssetSpec], AssetSpec], iter: Iterable[Union[AssetsDefinition, AssetSpec]]) -> Sequence[Union[AssetsDefinition, AssetSpec]]):
return [obj.map_specs(func) for obj in iter if isinstance(x, AssetsDefinition) else func(obj)]
my_specs_and_defs = ...
my_predicate: Callable[[AssetSpec], bool] = ...
my_updated_specs_and_defs = dg.map_specs(
lambda spec: spec.replace_attributes(owner="ben@dagsterlabs.com") if my_predicate(spec) else spec,
my_specs_and_defs
) This way, semantics match |
I find myself more convinced by The problem; I think we'll unfortunately end up with one of these for every kind of spec. IE; |
|
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.
Let's do a standalone function map_asset_specs
👍🏻
bb94e62
to
04fb74c
Compare
Introduced in #26109 |
04fb74c
to
8634ced
Compare
customer_metrics_dag_asset = customer_metrics_dag_asset.replace_attributes( | ||
customer_metrics_dag_asset, | ||
deps=[load_customers], | ||
) |
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.
The replace_attributes()
method is being called with customer_metrics_dag_asset
as both the receiver and first argument. Since this method only accepts keyword arguments, the first argument should be removed:
customer_metrics_dag_asset = customer_metrics_dag_asset.replace_attributes(
deps=[load_customers]
)
Spotted by Graphite Reviewer
Is this helpful? React 👍 or 👎 to let us know.
## Summary Based on conversation in #25941, introduces a new `dg.map_asset_specs` function which can be used to map a user-provided function over a set of `AssetSpec`s and `AssetDefinitions`. ```python @multi_asset(specs=[ AssetSpec(key="foo"), AssetSpec(key="bar"), ]) def my_multi_asset(): ... my_specs_and_defs = [ my_multi_asset, AssetSpec(key="external") ] my_mapped_specs_and_defs = map_asset_specs( lambda spec: spec.replace_attributes(owners="ben@dagsterlabs.com"), my_specs_and_defs ) ``` ## Test Plan New unit tests. ## Changelog > Introduced dg.map_asset_specs to enable modifying `AssetSpec`s and `AssetsDefinition`s in bulk.
#26027) ## Summary & Motivation Following an internal discussion [here](dagster-io/internal#12670) and product review [here](https://www.notion.so/dagster/Product-Reviews-1805443bfd5d4d40b3f6be8c79897295?p=13f18b92e4628020bd6fd3ac45f28af0&pm=s), get_asset_spec().key is the new recommended way to access the asset key in the Translator. Asset keys can now be customized in a custom translator using `replace_attributes`, like: ```python class MyCustomTableauTranslator(DagsterTableauTranslator): def get_asset_spec(self, data: TableauContentData) -> dg.AssetSpec: default_spec = super().get_asset_spec(data) return replace_attributes( default_spec, key=default_spec.key.with_prefix("prefix"), ) ``` This PR stack will be merged after #25941 lands, so that `replace_attributes()` can be called as `AssetSpec().replace_attributes()` These changes will also be done to the following integrations: - Power BI - Sigma - Looker - dlt - Sling - sdf We will need to rework dbt to use this pattern. ## How I Tested These Changes Updated unit test with BK
…ranslator (#26028) ## Summary & Motivation Mark DagsterTableauTranslator.get_asset_key as deprecated. To be removed in 1.10. This PR stack will be merged after #25941 lands, so that `replace_attributes()` can be called as `AssetSpec().replace_attributes()` ## Changelog [dagster-tableau] `DagsterTableauTranslator.get_asset_key` is deprecated in favor of `DagsterTableauTranslator.get_asset_spec().key`
) ## Summary Follow-on to #25941 which updates some non-type-checked `_replace` callsites to use these new methods.
Summary
Now that they've baked for a little bit, moves the
replace_attributes
andmerge_attributes
utilities directly ontoAssetSpec
, and marks them public:How I Tested These Changes
Update unit test.
Changelog