Open harrislapiroff opened 6 years ago
Ran into the same problem. Did the data migration manually outside the migration.
I also ran into this. The explanation above seems correct; in migrations calling save()
on a model calls the base Model.save()
method and thus skips the ClusterableModel.save()
call that would be necessary to persist the changes being made.
@harrislapiroff I was also able to use your suggested workaround of three migration steps:
AlterField
to a models.ManyToManyField
.RunPython
that does the data migration.AlterField
back to a modelcluster.fields.ParentalManyToManyField
.Another simpler option that seems to work (using an undocumented API on the field) is to manually invoke commit()
on the relation, e.g.
for entry in DirectoryEntry.objects.all():
topic_titles = list(entry.topics.values_list('title', flat=True))
entry.temporary_topics.set(
TemporaryTopic.objects.filter(title__in=topic_titles)
)
# This seems to commit the related objects, and doesn't require an entry.save() call.
entry.temporary_topics.commit()
This should be mentioned in some caveats on a frontpage I guess! :)
In a perverse coincidence, we had been using the workaround first Initial State -> ManyToMany -> RunPython -> ParentalManyToMany
, then decided to clean it up and do it the "correct way" e.g. Initial State -> ParentalManyToMany -> RunPython
. After hours of confusion eventually found this issue. Definitely needs to be called out on in the README!
Perhaps Andy's workaround with calling commit()
in the migration should/could be documented? Would the maintainers (@gasman ) foresee any issues with documenting that?
Ran into this issue as well!
Got around it by creating the new record using the through model instead
I ran into an issue writing a data migration for a
ParentalManyToManyField
today where the data migration wouldn't write any data to the tables for that field. The migration looked something like this:@gasman suspects the fake model that gets built by django's migration logic doesn't inherit from
ClusterableModel
and is therefore missing some of the logic necessary to make this data migration work.I ended up using a workaround in which I had a migration convert my
ParentalManyToManyField
s to Django's built-inManyToManyField
before the data migration and then another migration afterward to convert them back, which seems to have worked fine.