mirror of
https://github.com/go-admin-team/go-admin.git
synced 2026-09-23 18:58:09 +00:00
zhangwenjian
2c50317a98
The check grouped by (app_code, path, action) and refused whatever appeared more than once. GROUP BY treats two NULLs as the same value; a unique index treats them as different ones and allows both. So a database holding rows with a null path or action was refused for duplicates the index it was blocking would have accepted - and the migration stopped, on a database with nothing wrong with it. Both columns are nullable: neither carries a not-null tag, so gorm built them that way. Measured on MySQL 8.0, PostgreSQL 15 and SQLite: two rows with both columns null are one group to GROUP BY, and the unique index builds over them without complaint. Standard SQL, not a dialect quirk. They are now excluded from the check rather than grouped. Each column needs its own exclusion and has its own test: one null column is enough to make the index accept the pair, so removing either condition alone lets that half through - which is what the two subtests are for, and each fails only for its own half. The message could not name the rows either. MySQL's CONCAT returns NULL when any argument is, and scanning that into a string fails with "converting NULL to string is unsupported" - so the check reported a driver error instead of the duplicates it exists to report. SQLite and PostgreSQL treat a null argument as empty and say nothing, which is why this never surfaced in the tests: they run on SQLite, and this repository has no MySQL in CI. The comment says so, so that a postgres-only test file is not mistaken for cover. No COALESCE was added to paper over that. It would have had nothing left to guard once the nulls are excluded, and it would make a future regression quieter: someone dropping the exclusions would get a report naming rows that are not duplicates, which reads as a real answer, rather than a scan error that reads as a broken query. Leaving path and action nullable is deliberate. Tightening them is a migration of its own - existing null rows have to be given values, and what those values should be belongs to whoever owns the data, not to a migration whose job is adding an index.