--
Ticket URL: <https://code.djangoproject.com/ticket/30813>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* Attachment "photo_2019-09-27_18-12-35.jpg" added.
* status: new => closed
* version: 2.2 => master
* resolution: => invalid
Comment:
`dumpdata` dumps primary keys by default which don't exist anymore after
`flush`, so it's expected that such combination of commands fails. You
should try:
{{{
django-admin dumpdata --natural-foreign --natural-primary
}}}
to avoid dumping auto primary keys (see
[https://docs.djangoproject.com/en/2.2/ref/django-admin/#dumpdata
documentation]).
Closing per TicketClosingReasons/UseSupportChannels.
--
Ticket URL: <https://code.djangoproject.com/ticket/30813#comment:1>
Comment (by Maksych):
No, I tell about:
> python manage.py flush
My full actions:
> django-admin startproject project .
> python manage.py makemigrations
> python manage.py migrate
> python manage.py dumpdata > db.json
> python manage.py loaddata db.json
And all it's okay, but after:
> python manage.py flush
> python manage.py loaddata db.json
Raised exception because content-types after flush is diferent betwen
after migrate.
--
Ticket URL: <https://code.djangoproject.com/ticket/30813#comment:2>
Comment (by felixxm):
This is documented behavior, please take a look at
[https://docs.djangoproject.com/en/2.2/ref/django-admin/#flush flush
documentation]:
> Removes all data from the database and **re-executes any post-
synchronization handlers**. The table of which migrations have been
applied is not cleared. If you would rather start from an empty database
and re-run all migrations, **you should drop and recreate the database**
and then run migrate instead.
so `flush` removes all data from the database and **re-executes post-
synchronization handlers** which recreates `ContentType`'s with different
IDs.
--
Ticket URL: <https://code.djangoproject.com/ticket/30813#comment:3>