github-actions[bot] opened a new pull request, #72613:
URL: https://github.com/apache/airflow/pull/72613

   * Fix db migrate failure to Airflow 2.9.2 under PyMySQL driver
   
   Upgrading through revision 686269002441 raised
   pymysql.err.ProgrammingError because the migration used MySQL's
   PREPARE/EXECUTE/DEALLOCATE PREPARE dynamic SQL to conditionally drop
   unique constraints, which PyMySQL's driver does not support
   (see https://github.com/PyMySQL/PyMySQL/issues/202). Replaced with a
   plain lookup of existing constraints from
   information_schema.TABLE_CONSTRAINTS followed by conditional
   ALTER TABLE ... DROP INDEX statements, which works with any MySQL
   driver.
   
   Verified against a real MySQL/PyMySQL backend: downgrading to
   bff083ad727d and re-running db migrate now completes without error.
   
   closes: #43690
   
   * Add newsfragment for MySQL PyMySQL migration fix
   
   * Fix offline migration for 2.9.2 ORM-consistency revision
   
   The PyMySQL online-mode fix in this migration queries
   information_schema.TABLE_CONSTRAINTS via conn.execute() to decide which
   legacy unique constraints to drop. In Alembic's offline (--sql) mode
   there is no live connection, so conn.execute() returns None and
   iterating over it raises TypeError, breaking the CI "Test offline
   migration" step. Guard the query-then-conditionally-drop logic behind
   context.is_offline_mode(), falling back to the original dynamic
   prepare/execute/deallocate SQL text for the offline branch, since that
   text is only ever emitted as script output there rather than executed
   directly.
   
   * Address review feedback on MySQL PyMySQL migration fix
   
   Bind the table name as a query parameter in the information_schema
   lookup instead of interpolating it into the SQL string, since it's a
   value comparison rather than an identifier — matches Airflow's usual
   parameter-binding convention even though every call site currently
   passes a hardcoded literal. Also correct the docstring: PyMySQL can run
   a bare PREPARE statement fine, what it actually can't do is send more
   than one statement per cursor.execute() call, because it never enables
   CLIENT.MULTI_STATEMENTS.
   
   * Fixed the PR comments
   (cherry picked from commit 08e428ca8ab19975cb502972eb9c66eac3fd7a72)
   
   Co-authored-by: Aaryan Mahajan <[email protected]>


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to