@@ -237,7 +237,7 @@ That long-winded model test did serendipitously help us find unexpected
237
237
bugs, but now it's time to rewrite it. I wrote it in a very verbose style to
238
238
introduce the Django ORM, but in fact, we can get the same coverage from a
239
239
couple of much shorter tests.
240
- Delete `test_saving_and_retrieving_items` and replace with this:
240
+ Delete `test_saving_and_retrieving_items` and replace it with this:
241
241
242
242
[role="sourcecode"]
243
243
.lists/tests/test_models.py (ch13l010)
@@ -346,18 +346,11 @@ The problem is that we have at least one database record which used to be valid
346
346
but after introducing our new constraint, the `unique_together`, it's no longer
347
347
compatible.
348
348
349
- Just delete `src/db.sqlite3` and run the migration again. We can do this,
350
- because it's only a dev environment, and the data saved in the database isn't
351
- important.
349
+ To fix this problem, we can just delete `src/db.sqlite3` and run the migration again.
350
+ We can do this because the database on our laptop is only used for dev, so the data in it is not important.
352
351
353
- However, if we already have records we want to keep (which would be the case in
354
- a production environment, where we need to keep our users' data) we would need
355
- to do a bit more work and come up with a migration strategy for dealing with
356
- invalid--duplicate in this case--records.
357
- // CSANAD: I wanted to mention some articles from credible sources explaining
358
- // migration strategies, modifying migration scripts, etc
359
- // but all I found were either outdated, or clearly chatgpt-generated
360
- // articles.
352
+ In <chapter_deploying_validation>>, we'll deploy our new code to production,
353
+ and discuss what to do if we run into migrations and data integrity issues at that point.
361
354
362
355
Now if we change our duplicates test to do a `.save` instead of a
363
356
`.full_clean`...
@@ -789,7 +782,7 @@ AssertionError: '' != "You've already got this in your list"
789
782
790
783
The error message isn't being displayed because we are not using the Bootstrap
791
784
classes. Although it would have been nice to minimise hand-written html and
792
- utilise Django instead, it seems like we need to bring back our custom
785
+ use Django instead, it seems like we need to bring back our custom
793
786
`<input>` and add a few attributes manually:
794
787
795
788
[role="sourcecode"]
0 commit comments