Since my last post, I've discovered that the current implementation <https://github.com/durvalcarvalho/django/blob/0bcc03aba565b0b28436ce3633b0e5bba709f414/django/db/migrations/autodetector.py#L619> only handles simple ForeignKeys and not more complex cases like ManyToManyFields. This is because the current approach generates at least one AlterField <https://github.com/durvalcarvalho/django/blob/0bcc03aba565b0b28436ce3633b0e5bba709f414/django/db/migrations/autodetector.py#L755> with the fields ManyToOneRel and ManyToManyField, which cannot be serialized <https://github.com/django/django/blob/6cbc403b8ee7014bd6dae4892d404eedb1d4a50d/django/db/migrations/serializer.py#L369> at the time of writing operations to the migration files.
I'm still trying to figure out the best approach to tackle this issue. I'm unsure whether extending the serializer_factory to support these types of fields or creating a new operation (probably "MoveModel") similar to RenameModel would be the better solution. I noticed that in the RenameModel the operations related to column renaming in the M2M tables are done in the database_forwards <https://github.com/django/django/blob/6cbc403b8ee7014bd6dae4892d404eedb1d4a50d/django/db/migrations/operations/models.py#L370> method using the _alter_many_to_many <https://github.com/django/django/blob/6cbc403b8ee7014bd6dae4892d404eedb1d4a50d/django/db/migrations/operations/models.py#L411> . If anyone in the Django community has any suggestions or experience with this issue, I would greatly appreciate any input. Thank you! Em sexta-feira, 17 de fevereiro de 2023 às 16:56:01 UTC-3, Durval Carvalho escreveu: > Hello Django developers, > > I'm new to the community and I'm not sure if this is the right place to > ask my question, so please let me know if there's a more appropriate > channel for this type of discussion. > > I would like to ask for feedback on my approach. I have found what I > believe to be the best way to move a model from one app to another in > Django. It involves four separate operations in at least 3 different > migrations: > > 1. > > Rename table operation: renames the physical table name on the > database. This operation should be a SeparateDatabaseAndState operation > and > only change the database, without changing any state. > 2. > > Create table operation: moves the model code to the new app, and > creates a CreateModel only in state, with a SeparateDatabaseAndState > operation. > 3. > > Update all foreign keys that point to the moved model. > 4. > > Delete the old model table, but only in state, using a > SeparateDatabaseAndState operation. > > > I've implemented this logic in a new method called "generate_moved_models" > in MigrationAutodetector. > <https://github.com/durvalcarvalho/django/blob/b8a5155f474de8dadf92495d1ec9c668860aeb27/django/db/migrations/autodetector.py#L616> > > > This approach didn't break any existing tests, and now I'm focused on > writing the text using the moving model feature with other operations. > > Thank you all in advance for your feedback on this approach. > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/cada5a80-bb77-4f26-8a14-54f27b6c2d3cn%40googlegroups.com.
