n this issue, there were two problems with MySQL migration generation and schema pushing:
-
MySQL, like SQLite, does not have a difference in unique constraints and unique indexes at the database level. This aspect was handled correctly for SQLite but not for MySQL. In MySQL, when a
unique index
is created from a Drizzle schema, it is stored as both a unique constraint and a unique index in the database. Therefore, there was no distinction between the two. This led to incorrect assumptions during schema pushes regarding the creation, dropping, or storage of unique indexes. In the current fixes, Drizzle Kit now treats unique constraints as unique indexes for MySQL and SQLite only. -
Drizzle Kit was attempting to drop the primary key when it shouldn't have done so. The issue was with incorrect querying of the information schema. Drizzle Kit was examining the column definition and the
column_key
setting from theinformation_schema.columns table
. However, it turns out that thecolumn_key
value can indicatePRIMARY
even for columns that are bothUNIQUE
andNOT_NULL
. Which is correct in database terms, but not valid in the determination if this constraint was created as Primary Key.
I have made changes to address this problem by utilizing the information_schema.table_constraints
table, which provides a proper distinction between primary keys and columns with the combination of UNIQUE
and NOT_NULL
- ✍️ Added new collision check between the same names in unique indexes and unique constraints in schema(for MySQL)