mirror of
https://github.com/go-admin-team/go-admin.git
synced 2026-09-24 02:59:59 +00:00
zhangwenjian
9dd271ecab
1786700008000 added sys_menu.seed_code and left it NULL on every row that was already there. That is right for the host's own hand-placed menus: there is nothing to derive one from. An application's rows are in that population too, and for those it is derivable - menu_name is what identified them before the column existed. The natural-key lookup missed them, so a reseed inserted a second copy beside each one, and the new unique index could not object, because NULL never collides on MySQL, PostgreSQL or SQLite and is filtered out of the index on SQL Server. Claimed when the application is seeded rather than by a backfill migration. The value is only derivable where the spec's own Code is in hand: menuName concatenates two pascalCase strings and does not reverse, so a migration looking at menu_name alone would be guessing. For the same reason more than one match is refused and named rather than picked from - attaching an application's menu to whichever row the database returned first is the failure this is meant to prevent, not a smaller version of it. The match is scoped to the application's own app_code, so a row belonging to another application, or to the host, is not claimed. An adopted row then goes through the ordinary repair, so it comes out carrying what the spec says rather than what it held from before. Three degradations turn the new assertions red: not adopting at all, picking a row when there is more than one, and dropping the app_code from the match.