You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This error is due to duplicate usernames in the galaxy_user table on main.
The underlying cause is the absence of a unique constraint on the username field in the galaxy_user table. The constraint exists in the model definition, but not in the database. There is no way to tell how and when the database schema on main was updated (the model definition blame history goes back 15+ years), but it's obvious that the constraint was never created on the database. This does not concern instances with a newer database.
The unique constraint on the username field should be added to the database via migration, which will ensure that older instances will have their databases updated once the migration is run.
The same applies to the email field: there should be a unique constraint (which, unlike username, is not defined in the model). This, too, should be added via migration.
In both cases, the migration should include a data migration to fix the duplicate records that would prevent these edits to the db schema. Deduplication can be handled via existing logic (see #18379 for similar example).
Galaxy version: 24.1
Specific error: duplicate usernames in galaxy_user table cause MultipleResultsFound errors when selecting one-or-none by username
Sentry error: https://sentry.galaxyproject.org/share/issue/7f671f6ec69f48d7bd5ae407e488f4f5/
This error is due to duplicate usernames in the galaxy_user table on main.
The underlying cause is the absence of a unique constraint on the username field in the galaxy_user table. The constraint exists in the model definition, but not in the database. There is no way to tell how and when the database schema on main was updated (the model definition blame history goes back 15+ years), but it's obvious that the constraint was never created on the database. This does not concern instances with a newer database.
The unique constraint on the username field should be added to the database via migration, which will ensure that older instances will have their databases updated once the migration is run.
The same applies to the email field: there should be a unique constraint (which, unlike username, is not defined in the model). This, too, should be added via migration.
In both cases, the migration should include a data migration to fix the duplicate records that would prevent these edits to the db schema. Deduplication can be handled via existing logic (see #18379 for similar example).
To do:
The text was updated successfully, but these errors were encountered: