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
Our new policy with database migrations is that the migration must be done in its own PR. Prod should be migrated (by a lead) and the migration should be merged before the rest of the work is done. For this specific issue, be careful to check that all planner names are unique first. If a sufficiently large amount of users have non-unique planner names, this may require a migration script.
Context
The frontend UI prevents users from creating roadmaps with duplicate names, and thus expects all roadmaps to have a unique name.
As a result of a bug (or an intentionally bad query) it's possible for a user to have two planners with the same name. This shouldn't break backend logic, but does break the frontend UI, resulting in deletion/duplication problems.
Requirements
Constrain (user ID, planner name) to be unique for the planner table. Ensure that errors are handled gracefully/reported well in the case that a user somehow tries to save two planners with the same name. Carefully see the note above
Note
Our new policy with database migrations is that the migration must be done in its own PR. Prod should be migrated (by a lead) and the migration should be merged before the rest of the work is done. For this specific issue, be careful to check that all planner names are unique first. If a sufficiently large amount of users have non-unique planner names, this may require a migration script.
Context
The frontend UI prevents users from creating roadmaps with duplicate names, and thus expects all roadmaps to have a unique name.
As a result of a bug (or an intentionally bad query) it's possible for a user to have two planners with the same name. This shouldn't break backend logic, but does break the frontend UI, resulting in deletion/duplication problems.
Requirements
Constrain (user ID, planner name) to be unique for the planner table. Ensure that errors are handled gracefully/reported well in the case that a user somehow tries to save two planners with the same name. Carefully see the note above