Conversation
2e8d220 to
9f818c2
Compare
2b1699c to
ea56fea
Compare
The asset name, uri and group columns hard-code the latin1_general_cs collation on MySQL. Several MySQL-compatible engines do not provide that collation, so Airflow cannot create its own schema on them even though the rest of the database works. There is no way to override it from outside, because the collation is baked into the ORM column definitions. closes: apache#31373 Signed-off-by: 1fanwang <1fannnw@gmail.com>
The asset name/uri/group columns carry an explicit MySQL collation so their 1500-character unique indexes stay inside the 3072-byte index limit. That collation is configurable on the models, but the migrations that create and alter those columns still hard-coded `latin1_general_cs`, so the setting only took effect when the schema was created from the ORM. A fresh install on a MySQL-compatible engine that lacks that collation replays the migrations instead and fails on the first asset table, which leaves the setting useless in exactly the case it was added for. Resolve the collation at migration run time through the same configuration key the models read. Signed-off-by: 1fanwang <1fannnw@gmail.com>
The setting controls both ORM table creation and historical migrations, so both paths need focused coverage to keep unsupported hard-coded collations from returning. Signed-off-by: 1fanwang <1fannnw@gmail.com>
Helper tests alone would not catch a migration reverting to the unsupported hard-coded collation. Render the full MySQL migration chain with the override and assert every emitted asset collation uses it. Signed-off-by: 1fanwang <1fannnw@gmail.com>
Two historical downgrades recreate indexed asset columns. Render both MySQL downgrade paths with the override so an unsupported hard-coded collation cannot return there. Signed-off-by: 1fanwang <1fannnw@gmail.com>
850c074 to
e8e3527
Compare
|
Hello @1fanwang - thank you for your contributions to Apache Airflow! The Airflow community has introduced a limit of 5 open pull requests at a time for contributors without write access to the repository. You currently have 34 open pull requests, so - as a one-time step of introducing the limit - we closed the ones where maintainers have not engaged yet:
These pull requests stay open because maintainers are already engaged in them - they count towards your limit:
This is not a judgement of you or of your changes. We never told contributors before that opening many pull requests at once was a problem, so there is nothing to feel bad about - and nothing is lost: your branches, commits and the review history stay where they are. What we ask you to do is to make your first prioritization decision: choose which of the pull requests above matter most to you, and reopen them (up to 5 open at a time, including the ones still open) with the "Reopen pull request" button or While your pull requests are waiting for review, the most valuable thing you can do is help in other ways - reviewing other contributors' pull requests, helping with issues, and taking part in the discussions on the devlist and Slack. Why we introduced the limit, what it means for you and how to reopen or restore a pull request is explained in https://github.com/apache/airflow/blob/main/contributing-docs/32_open_pull_request_limit.rst. Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting |
Fresh MySQL-compatible installs fail without
latin1_general_cs. Airflow uses single-byte collation to fit 1,500-character indexes.A database setting now controls ORM and migration collations.
Fixes #31373
Testing Done
Tested against TiDB 8.5.1.
Raw logs
Was generative AI tooling used to co-author this PR?
Generated-by: GitHub Copilot CLI (GPT-6 Astra) following the guidelines