Spike: Evaluate allowing duplicates for id range migration

Problem

The plans table migration to a static table will take several milestones for a safe migration. It may be possible to speed the transition by allowing a duplicate name and setting the new rows id range to our intended FixedItemsList ids.

• Evaluate the complexity of allowing duplicate names
• Identify risks and dependencies
• Create a basic POC to validate the transition

Proposal

1. Update model methods to return latest records to handle duplicates.
2. Create a migration that temporarily drops the unique constraint on name and adds the constraint back with NOT VALID or doesn’t add it back since we plan to drop the table in the future, add duplicates of the rows we want at fixed ids with some offset (e.g. 101,102,etc).
3. Create a migration to update related tables to the new id ranges.
4. Create a migration to drop the FK constraints.
5. Update the model to a FixedItemsModel with the new fixed ids we updated to hardcoded.

Concerns

• Higher risk and complexity in maintaining existing model functionality. For example any find or query operation may return duplicates, the same applies to updates and deletion possibly applying to multiple records.