Re: Feature request: Allow to process data-migrations after flush

[Alan Arellano]

Precisely, because data migrations are indeed supported, it should be an option.

Today I'm in other situation, I have a data migration which requires being run several times (because updates needed data from remote sources), today I can't do this with an straightforward command.

On 08/26/2017 04:58 AM, Adam Johnson wrote:

I've always thought flush is a weird command because an empty database is very normally useless, because of data migrations. The docs do even say:

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.

You can achieve this with:

./manage.py dbshell <<< 'drop database foo; create database foo <charset utf8mb4 or any other options you need>;'

./manage.py migrate

I've wrapped this up in the big application I work on with a separate management command that basically does:

assert settings.DEBUG

cursor.execute('drop database; create database...')

call_command('migrate')

I think this solves your problem better than any change to migrations. Executing "just one migration out of order" is not generally possible unless it's strictly a data migration.

On 26 August 2017 at 00:41, Alan Arellano <ro...@solucioneslibres.com> wrote:

Currently it's somewhat difficult to process initial data after a flush. You will need to fake the database state...

In my case I'm creating all tables of the project with the migration 0001 and populating with initial data on migration 0002.

After spending a time looking for solutions found that I could achieve the desired result with:
python manage.py flush
python manage.py migrate app 0001 --fake
python manage.py migrate app 0002
python manage.py migrate app --fake

While this works might be confusing (and risky), since django is indeed providing data-migrations, makes sense that after flushing the database one could repopulate the database easily. Since making 'flush' not to delete the data-migrations data seems overly complicated or simply impossible in real-world, makes sense to be able to --force a particular migration without touching others.

Hope to read your comments. Greetings!

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bcb956ac-54b8-22e4-544e-a65c84647bdb%40solucioneslibres.com.
For more options, visit https://groups.google.com/d/optout.

--

Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM32wOdry-Ls%3DUYz7VLdLUZ8fCNv5ce%3DN%3Di7HcM7-i3JRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.