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

Get rid of AssetAliasCondition #44708

Merged

Conversation

uranusjr
Copy link
Member

@uranusjr uranusjr commented Dec 5, 2024

Instead of having a separate class for condition evaluation, we can just use the main AssetAlias class directly. While it technically makes sense to subclass AssetAny, AssetAliasCondition does not really reuse much of its implementation, and we can just implement the missing methods ourselves instead. Whether the class actually is an AssetAny does not really make much of a difference.

This actually allows us to simplify quite some code (including tests) a bit since we don't need to rewrap AssetAlias back and forth.

Instead of having a separate class for condition evaluation, we can just
use the main AssetAlias class directly. While it technically makes sense
to subclass AssetAny, AssetAliasCondition does not really reuse much of
its implementation, and we can just implement the missing methods
ourselves instead. Whether the class actually is an AssetAny does not
really make much of a difference.

This actually allows us to simplify quite some code (including tests) a
bit since we don't need to rewrap AssetAlias back and forth.
@Lee-W Lee-W self-requested a review December 6, 2024 00:19
@uranusjr uranusjr marked this pull request as ready for review December 6, 2024 00:54
@uranusjr uranusjr merged commit cccc933 into apache:main Dec 6, 2024
68 checks passed
@uranusjr uranusjr deleted the alias-condition-only-resolve-when-needed branch December 6, 2024 03:05
Ohashiro pushed a commit to Ohashiro/airflow that referenced this pull request Dec 6, 2024
* Get rid of AssetAliasCondition

Instead of having a separate class for condition evaluation, we can just
use the main AssetAlias class directly. While it technically makes sense
to subclass AssetAny, AssetAliasCondition does not really reuse much of
its implementation, and we can just implement the missing methods
ourselves instead. Whether the class actually is an AssetAny does not
really make much of a difference.

This actually allows us to simplify quite some code (including tests) a
bit since we don't need to rewrap AssetAlias back and forth.

* Fix serialization test

* Does not need this call

* Remove resolution-dependant timetable summary
LefterisXefteris pushed a commit to LefterisXefteris/airflow that referenced this pull request Jan 5, 2025
* Get rid of AssetAliasCondition

Instead of having a separate class for condition evaluation, we can just
use the main AssetAlias class directly. While it technically makes sense
to subclass AssetAny, AssetAliasCondition does not really reuse much of
its implementation, and we can just implement the missing methods
ourselves instead. Whether the class actually is an AssetAny does not
really make much of a difference.

This actually allows us to simplify quite some code (including tests) a
bit since we don't need to rewrap AssetAlias back and forth.

* Fix serialization test

* Does not need this call

* Remove resolution-dependant timetable summary
got686-yandex pushed a commit to got686-yandex/airflow that referenced this pull request Jan 30, 2025
* Get rid of AssetAliasCondition

Instead of having a separate class for condition evaluation, we can just
use the main AssetAlias class directly. While it technically makes sense
to subclass AssetAny, AssetAliasCondition does not really reuse much of
its implementation, and we can just implement the missing methods
ourselves instead. Whether the class actually is an AssetAny does not
really make much of a difference.

This actually allows us to simplify quite some code (including tests) a
bit since we don't need to rewrap AssetAlias back and forth.

* Fix serialization test

* Does not need this call

* Remove resolution-dependant timetable summary
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants