From quite some trial and error I conclude that signals are disabled for MigratorTestCase. Is that really so? How is this done? Can they be enabled generally without replicating the receiver functions from the model?
Is it okay to use asserts within the prepare function of the MigratorTestCase?
As a side note, I originally tried to create the missing profiles in the migration via user.profile = Profile() as I thought the one-to-one relationship would allow this but changed it to Profile(user=user) to make it work. Can the first version be used at all?
It seems it’s done here, for the pre and post migrate signals, by directly mutating the attributes on the signal object:
I saw the _pre_setup method but thought it would have no effect on post_save receivers since it’s about pre_migrate and post_migrate receivers. And it’s a list instead of a dictionary (but I don’t know yet how signals are handled internally, just assuming).
I presume so but it feels like this is a question for that project, which you could do in a GitHub issue.
This package’s prepare method is not that different from other tests’ setup method. So it’s not a question exclusive for that project’s GitHub I think. Anyway, I will certainly ask them of their thoughts on the topic.
I don’t believe the first version can be used.
Thought so but good to have another opinion on that.
Ah, that’s the signal you’re after. I think the signal isn’t attached because you aren’t using the original model in your migration, but a temporary “historical” version of it from get_model , as per the first paragraph of the RunPython docs. If you want the signal to fire you’ll have to reattach it.
I think the signal isn’t attached because you aren’t using the original model in your migration, but a temporary “historical” version of it from get_model
I thought about that as well. But the migration I start from was created with the same change the post_saves were introduced. So I would think those should be loaded at the same time. Does get_model use the files’ timestamps?
get_model returns a brand new in-memory class with the current fields. It is unrelated to the model class in your source code, and any attached signal handlers, and only built from the executed state in your migration files.