Skip to content
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

Extract InOutMapper to begin refactoring AssetsDefinition construction process #22222

Merged
merged 1 commit into from
Jun 6, 2024

Conversation

schrockn
Copy link
Member

@schrockn schrockn commented Jun 2, 2024

Summary & Motivation

multi_asset is a beast, as well as the entire AssetsDefinition creation machinery.

This class introduces a class InOutMapper (renamed to AssetsDefinitionFactory upstack once its mandate increased) that begins to tease apart multi_asset which is nearly 300 LoC, has 37 local variables, and a huge dynamically scoped inner function.

To see where this is going I have created a digest PR that demonstrate the before after.

This also sets us up to consolidate the AssetsDefinition creation code paths, as it contains tons of duplicated code strewn about. Instead we will be able to invoke the decomposed code in the new factory functions.

This was motivated by the discussion in #22221 that suggested we move a propose class to be within the inheritance hierarchy of AssetsDefinition. The complexity of logic surrounding the construction of said object is completely out of control, and I found it effectively intractable to do an inheritance scheme cleanly.

How I Tested These Changes

BK

@schrockn schrockn force-pushed the aget-multi-asset-refactor-1 branch from e23b6f8 to b2757bf Compare June 2, 2024 20:45
@schrockn schrockn changed the title Extract InOutMapper to begin refactoring AssetsDefinition constructor Extract InOutMapper to begin refactoring AssetsDefinition construction process Jun 3, 2024
@schrockn schrockn requested review from smackesey and sryza June 3, 2024 10:44
@schrockn schrockn marked this pull request as ready for review June 3, 2024 10:44
@schrockn schrockn requested a review from sryza June 3, 2024 15:01
@schrockn schrockn dismissed sryza’s stale review June 3, 2024 15:01

popping back to your q

@schrockn schrockn requested review from sryza and removed request for sryza June 3, 2024 15:01
@schrockn
Copy link
Member Author

schrockn commented Jun 3, 2024

@sryza feedback addressed in #22251

This was referenced Jun 8, 2024
salazarm pushed a commit that referenced this pull request Jun 10, 2024
…n process (#22222)

## Summary & Motivation

`multi_asset` is a beast, as well as the entire `AssetsDefinition` creation machinery.

This class introduces a class `InOutMapper` (renamed to `AssetsDefinitionFactory` upstack once its mandate increased) that begins to tease apart `multi_asset` which is nearly 300 LoC, has 37 local variables, and a huge dynamically scoped inner function.

To see where this is going I have created a digest [PR](#22238) that demonstrate the before after.

This also sets us up to consolidate the `AssetsDefinition` creation code paths, as it contains tons of duplicated code strewn about. Instead we will be able to invoke the decomposed code in the new factory functions.

This was motivated by the discussion in #22221 that suggested we move a propose class to be within the inheritance hierarchy of `AssetsDefinition`. The complexity of logic surrounding the construction of said object is completely out of control, and I found it effectively intractable to do an inheritance scheme cleanly.

## How I Tested These Changes

BK
danielgafni pushed a commit to danielgafni/dagster that referenced this pull request Jun 18, 2024
…n process (dagster-io#22222)

## Summary & Motivation

`multi_asset` is a beast, as well as the entire `AssetsDefinition` creation machinery.

This class introduces a class `InOutMapper` (renamed to `AssetsDefinitionFactory` upstack once its mandate increased) that begins to tease apart `multi_asset` which is nearly 300 LoC, has 37 local variables, and a huge dynamically scoped inner function.

To see where this is going I have created a digest [PR](dagster-io#22238) that demonstrate the before after.

This also sets us up to consolidate the `AssetsDefinition` creation code paths, as it contains tons of duplicated code strewn about. Instead we will be able to invoke the decomposed code in the new factory functions.

This was motivated by the discussion in dagster-io#22221 that suggested we move a propose class to be within the inheritance hierarchy of `AssetsDefinition`. The complexity of logic surrounding the construction of said object is completely out of control, and I found it effectively intractable to do an inheritance scheme cleanly.

## How I Tested These Changes

BK
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants