(1) get_or_create() calls get() with kwargs that are not “default”; if there are no such kwargs, get() executes the initial queryset, which gets all the records in the regions table. So the first time get_or_create() runs, there are no records in the table, and so it does an insert; but the second time, it finds one record, so it doesn’t do an insert, and same for all the subsequent calls of get_or_create().
(2) In order for this migration to run again in the dev environment, we'll have to, before merging this in:
(a) Delete the 0038 row in the django_migrations table
(b) Delete the indices associated with the unique constraint on the name column (attempting to run the migration again
without doing so will result in an error because the migration would be trying to create duplicate indices). To see the
indices we have to delete, go into the db container and run psql, and then run the "\d regions" command to see the
names of the indices (there should be 2 of them, a "like" and a "uniq".
Remarks:
(1) get_or_create() calls get() with kwargs that are not “default”; if there are no such kwargs, get() executes the initial queryset, which gets all the records in the regions table. So the first time get_or_create() runs, there are no records in the table, and so it does an insert; but the second time, it finds one record, so it doesn’t do an insert, and same for all the subsequent calls of get_or_create().
(2) In order for this migration to run again in the dev environment, we'll have to, before merging this in: (a) Delete the 0038 row in the django_migrations table (b) Delete the indices associated with the unique constraint on the name column (attempting to run the migration again without doing so will result in an error because the migration would be trying to create duplicate indices). To see the indices we have to delete, go into the db container and run psql, and then run the "\d regions" command to see the names of the indices (there should be 2 of them, a "like" and a "uniq".