@@ -330,6 +330,45 @@ Migrations for 'lists':
330
330
- Alter unique_together for item (1 constraint(s))
331
331
----
332
332
333
+ Now let's run the migration:
334
+
335
+ [subs="specialcharacters,macros"]
336
+ ----
337
+ $ pass:quotes[*python manage.py migrate*]
338
+ ----
339
+
340
+ When you run the migration, you may encounter the following error:
341
+ [subs="specialcharacters,macros"]
342
+ ----
343
+ $ pass:quotes[*python manage.py migrate*]
344
+ Operations to perform:
345
+ Apply all migrations: auth, contenttypes, lists, sessions
346
+ Running migrations:
347
+ Applying lists.0005_alter_item_unique_together...Traceback (most recent call last):
348
+ [...]
349
+ sqlite3.IntegrityError: UNIQUE constraint failed: lists_item.list_id, lists_item.text
350
+
351
+ [...]
352
+ django.db.utils.IntegrityError: UNIQUE constraint failed: lists_item.list_id, lists_item.text
353
+ ----
354
+
355
+ The problem is that we have at least one database record which used to be valid
356
+ but after introducing our new constraint, the `unique_together`, it's no longer
357
+ compatible.
358
+
359
+ Just delete `src/db.sqlite3` and run the migration again. We can do this,
360
+ because it's only a dev environment, and the data saved in the database isn't
361
+ important.
362
+
363
+ However, if we already have records we want to keep (which would be the case in
364
+ a production environment, where we need to keep our users' data) we would need
365
+ to do a bit more work and come up with a migration strategy for dealing with
366
+ invalid--duplicate in this case--records.
367
+ // CSANAD: I wanted to mention some articles from credible sources explaining
368
+ // migration strategies, modifying migration scripts, etc
369
+ // but all I found were either outdated, or clearly chatgpt-generated
370
+ // articles.
371
+
333
372
Now if we change our duplicates test to do a `.save` instead of a
334
373
`.full_clean`...
335
374
0 commit comments