fix typo in dag_schedule_dataset_alias_reference migration file

[Lee-W]

backport https://github.com/apache/airflow/pull/43245/files#diff-465bfca34e4030692c541248495b5abfe4deea606db126241dade041746fbd60

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[shahar1]

Static checks fail for some reason

[kaxil]

Hmm not so sure about just renaming constraints. What about folks who are already on this version?

[Lee-W]

Hmm not so sure about just renaming constraints. What about folks who are already on this version?

These reflect how the actual model is defined. As no feature is expected to be added to this version, I think these columns won't change in the future either.

[kaxil]

Hmm not so sure about just renaming constraints. What about folks who are already on this version?

These reflect how the actual model is defined. As no feature is expected to be added to this version, I think these columns won't change in the future either.

If you download Airflow 2.8.0, run airflow db migrate, upgrade to 2.10.2 and run airflow db migrate again with Postgres or MySQL backend, the constraints are created with the old names. Example:

If we merge and ship this change, we will have some users with dsdar_dag_fkey as name of constraint and some on dsdar_dataset_fkey. In future, if we need to access a constraint in another migration via name that won't work for some users.

This is true for folks upgrading from let's say Airflow 2.8.0 to 2.10.2 --> for those folks tables are created from "migration" . It is only for new Airflow 2.10.0 user where all tables are just created from ORM.

[potiuk]

Yep. Agree with @kaxil. That should be a separate migration. Also the original cahnge in main should be reverted and re-applied after that because people will go eventually 2.x -> 2.11 -> 3.x and things will break for them.

[Lee-W]

Got it. makes sense. I will create a fix pr to the main as well

[kaxil]

Unfortunately, we will have to do a little more here @Lee-W because we already have the case where the constraint is named differently for 2 different sets of users:

It is named

1. dsdar_dataset_fkey : for 2.8.0 -> 2.10.2: because they are created from migration
2. dsdar_dataset_alias_fkey: for new install 2.10.2: because they are created from model

So you will have to do similar if/else condition as you did on L85. Otherwise this might result in constraint not found error for folks with Case (2) above

[kaxil]

hmm? If the new name of constraint in migration is dsdar_dag_fkey, why are we changing this?