How can I send signals from within Django migrations?

Question

I use Django 1.7 migrations, and in particular, want to populate a newly-created database with initial data. Thus, I use a data migration for this. It looks like this:

def populate_with_initial_data(apps, schema_editor):
    User = apps.get_model("auth", "User")
    new_user = User.objects.create(username="nobody")

class Migration(migrations.Migration):

    ...

    operations = [
        migrations.RunPython(populate_with_initial_data),
    ]

At the same time, I want to have an instance of the UserDetails model for every new user:

@receiver(signals.post_save, sender=django.contrib.auth.models.User)
def add_user_details(sender, instance, created, **kwargs):
    if created:
        my_app.UserDetails.objects.create(user=instance)

But: This signal works only outside the migration. The reason is that apps.get_model("auth", "User") is different enough from django.contrib.auth.models.User that no signal is sent. If I try to do it manually, like this, it fails:

signals.post_save.send(django.contrib.auth.models.User, instance=julia, created=True)

This fails because then, the signal handler tries to create a new UserDetails pointing with O2O to a historical User:

ValueError: Cannot assign "<User: User object>": "UserDetails.user" must be a "User" instance.

Bummer.

Okay, I could call the signal handler directly. But I had to pass the historical UserDetails class in a keyword argument (and other historical classes that it needs). Besides, the app with the UserDetails is not the one with this data migration, so this would be an ugly dependency which easily may break, e.g. if the UserDetails app is removed from INSTALLED_APPS.

So, is this simply a current limitation that I have to address with ugly code and a FixMe comment? Or is there a way to send signals out of data migrations?

Yes, using signal.post_migrate because this *is* called. But it still needs code which should be not necessary. — Torsten Bronger, Oct 25 '14 at 07:29
You should post the answer and accept your own answer as this question is sitting at the top of the unanswered django questions. — dotcomly, Oct 24 '15 at 01:33

score 13 · Answer 1 · answered Oct 27 '15 at 11:36

You can't (and should not) do this because when your migration is executed, your UserDetails could be really different than when you wrote this migration. This is why django (and south) use "frozen models" which are identical to when you wrote the migration.

"Unfortunately", you have to freeze your signal code in your migration to keep the behaviour expected at the time you write the migration.

A simple exemple to understand why it's important to not use real models (or signals etc.) inside a migration :

Today, I could have this :

class UserDetails(models.Model):
    user = models.ForeignKey(...)
    typo_fild = models.CharField(...)

@receiver(signals.post_save, sender=django.contrib.auth.models.User)
def add_user_details(sender, instance, created, **kwargs):
    if created:
        UserDetails.objects.create(user=instance, typo_fild='yo')

Then, I have a data migration (called "populate_users") which create new users and I force the execution of add_user_details inside it. It's okay : it works today.

Tomorrow, I fix my typo_fild -> typo_field inside UserDetails and inside add_user_details. A new schema migration is created to rename the field in the database.

At this point, my migration "populate_users" will fail because when a new user will be created, it will try to create a new UserDetails with a field "typo_field" wich does not yet exist in the database : this field will only be rename in the DB with the next migrations.

So, if I want to keep a good migration wich will work at anytime, I have to copy the behaviour of add_user_details inside the migration. This freeze of add_user_details will have to use the frozen model UserDetails via apps.get_model("myapp", "UserDetails") and create a new UserDetails with the typo_fild which is frozen too.

You can always shoot in your foot if you wish. After all, other signals *are* sent, and I use them for solving this issue now. If you apply problematic changes to the model, you can use introspection in the signal handler. "Make the frequent case simple, and the rare case possible." — Torsten Bronger, Oct 27 '15 at 12:03

score 0 · Answer 2 · answered Dec 07 '21 at 10:07

Another option is to simply import the model as you normally would inside your populate_with_initial_data function:

def populate_with_initial_data(apps, schema_editor):
    from django.auth.models import User
    new_user = User.objects.create(username="nobody")

This has the significant drawback that the migration might break if you try to run it at at later time and the database schema has changed in a significant way since. In the case your are mentioning that seems unlikely but that must be assessed on a case by case basis.

We have several models where there are so many things happening on save() and in signals that we feel non frozen imports is the best option. In practice it's not a big problem (for us) and to mitigate the problem further we regularly prune all our migrations.

How can I send signals from within Django migrations?

2 Answers2

Linked