-
Notifications
You must be signed in to change notification settings - Fork 16.4k
Drop execution_date unique constraint on DagRun #41818
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
Conversation
5282e03 to
c14aff3
Compare
c14aff3 to
518767f
Compare
sunank200
left a comment
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.
I think the tests has to change as well
|
Fixed. If this passes, I think it can be merged first. |
2181c46 to
b28fa5a
Compare
d87ad4a to
5145387
Compare
kaxil
left a comment
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.
It isn’t breaking change but might be worth mentioning in Towncrier notes as a note-worthy change if someone is using combination of dag_id & execution_date to retrieve DagRuns
The column has also been renamed to logical_date, although the Python model is not changed. This allows us to not need to fix all the Python code at once (we'll do that later), but still do the two changes in one migration instead of two.
This seems to affect SQLite.
This seems to work with SQLite. Alembic is stupid...
aadab74 to
8d52673
Compare
|
I think it is more appropriate to attach the news fragment on the next PR that will rename the attribute on DagRun instead. That one is the actual breaking change most people will notice. This PR only affects the SQL layer, not Python. Having separate fragments for changes in each layer will likely be a bit confusing. |
The column has also been renamed to logical_date, although the Python model is not changed. This allows us to not need to fix all the Python code at once (we'll do that later), but still do the two changes in one migration instead of two.
Note that this one is not breaking—the metadatabase interface is not user-facing, we’re only removing a check that stopped impossible things.