Migrations are applied with no errors when upgrading Nautobot to version 2.x.
Observed Behavior
Getting UniqueViolation error when applying migration nautobot_golden_config.0029_alter_configplan_unique_together.
Running migrations:
Applying nautobot_golden_config.0029_alter_configplan_unique_together...Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/django/db/backends/utils.py", line 84, in _execute
return self.cursor.execute(sql, params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/django_prometheus/db/common.py", line 69, in execute
return super().execute(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.UniqueViolation: could not create unique index "nautobot_golden_config_c_plan_type_device_id_crea_dc70e69e_uniq"
DETAIL: Key (plan_type, device_id, created)=(remediation, 2630e072-de7f-4391-bf0c-aa77171ba1b4, 2024-02-23 00:00:00+00) is duplicated.
Steps to Reproduce
While still in Nautobot v1.6, create two Config Plans for the same Device, both with the same type (e.g. remediation). Make sure that both are created on the same date.
Upgrade Nautobot.
During migration 0028_auto_20230916_1712_part2, the field created for model ConfigPlan is changed from DateField to DateTimeField.
The migrated ConfigPlans that were created on the same date have the same value under DateTimeField too.
When the migration nautobot_golden_config_c_plan_type_device_id_crea_dc70e69e_uniq is subsequently applied, the tuple that determines uniqueness (plan type, device, created) fails as the plans created in step 1 have all three factors identical.
Workaround used, maybe inspiration for a fix
The time portion of the freshly created DateTimeField "created" was randomized in order to have a unique (type, device, created) tuple for every entry. I suppose that something similar to that should be incorporated in a migration after 0028 but before 0029.
Environment
Expected Behavior
Migrations are applied with no errors when upgrading Nautobot to version 2.x.
Observed Behavior
Getting
UniqueViolationerror when applying migrationnautobot_golden_config.0029_alter_configplan_unique_together.Steps to Reproduce
remediation). Make sure that both are created on the same date.0028_auto_20230916_1712_part2, the fieldcreatedfor modelConfigPlanis changed fromDateFieldtoDateTimeField.DateTimeFieldtoo.nautobot_golden_config_c_plan_type_device_id_crea_dc70e69e_uniqis subsequently applied, the tuple that determines uniqueness (plan type, device, created) fails as the plans created in step 1 have all three factors identical.Workaround used, maybe inspiration for a fix
The
timeportion of the freshly createdDateTimeField"created" was randomized in order to have a unique (type, device, created) tuple for every entry. I suppose that something similar to that should be incorporated in a migration after 0028 but before 0029.