-
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
[external-assets] Hoist resolution of input asset keys to RepositoryDataBuilder #20186
[external-assets] Hoist resolution of input asset keys to RepositoryDataBuilder #20186
Conversation
2c4a5a8
to
0625561
Compare
66ff903
to
00eb64c
Compare
0625561
to
58dcd97
Compare
00eb64c
to
2f03e42
Compare
58dcd97
to
8beb90c
Compare
ae90738
to
5003390
Compare
Deploy preview for dagster-docs ready! Preview available at https://dagster-docs-8nzhr4fkf-elementl.vercel.app Direct link to changed pages: |
5003390
to
072ed7a
Compare
072ed7a
to
c2031ac
Compare
9fa2ff0
to
42c75ff
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.
An excellent change.
It would be great if we could test that AssetsDefinition has fully resolved dependencies and check invariants at appropriate entry points to ensure that they don't sneak through.
Put another way, at what point is it illegal to pass in an AssetsDefinition
to one of our APIs?
def resolve_asset_job( | ||
assets: Sequence[Union[AssetsDefinition, SourceAsset]], | ||
*, | ||
selection: Optional[CoercibleToAssetSelection] = None, | ||
name: str = "asset_job", | ||
resources: Mapping[str, object] = {}, | ||
**kwargs: Any, | ||
) -> JobDefinition: | ||
assets_defs = [a for a in assets if isinstance(a, AssetsDefinition)] | ||
source_assets = [a for a in assets if isinstance(a, SourceAsset)] | ||
selection = selection or assets_defs | ||
return Definitions( | ||
assets=[*assets_defs, *source_assets], | ||
jobs=[define_asset_job(name, selection, **kwargs)], | ||
resources=resources, | ||
).get_job_def(name) |
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.
why call this "resolve" asset job?
create_asset_job_from_assets
? or something?
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, it was bc we are getting the result of define_asset_job(...).resolve(...)
but "resolution" here is kind of an implementation detail. Changed to create_test_asset_job
.
42c75ff
to
5401f3b
Compare
I think all of our public APIs go through a |
…ataBuilder (#20186) ## Summary & Motivation We have some hairy logic that resolves "relative" asset keys associated with asset inputs. Currently this resolution is done in multiple internal places, which complicates internal codepaths dealing with assets. This PR hoists resolution to repository build time, in the same place that we convert source assets to assets def. This simplifies internal pathways. In order to support this change, I had to alter tests that were directly calling `UnresolvedAssetsJobDefinition.resolve` with an `AssetGraph` to instead go through repository construction. With the external asset conversion happening at the repo level, this is something that needed to be done anyway. ## How I Tested These Changes Existing test suite
Summary & Motivation
We have some hairy logic that resolves "relative" asset keys associated with asset inputs. Currently this resolution is done in multiple internal places, which complicates internal codepaths dealing with assets.
This PR hoists resolution to repository build time, in the same place that we convert source assets to assets def. This simplifies internal pathways.
In order to support this change, I had to alter tests that were directly calling
UnresolvedAssetsJobDefinition.resolve
with anAssetGraph
to instead go through repository construction. With the external asset conversion happening at the repo level, this is something that needed to be done anyway.How I Tested These Changes
Existing test suite