--
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/8869b1cb-2b92-4e05-823a-92e72308fc23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Wouldn't a workaround be to call create_contenttypes() in a RunPython in your app's migration before inserting the data which depends on the content types?
Starting with "There is a huge issue with content types framework" isn't a good way to motivate them.
Speaking for myself, I would be more eager to investigate if you skipped the hyperbole and remained neutral, for example "I'm facing an issue with the content types framework".
You'd have more success if you managed to write in a positive style.
I think the issue itself is valid. I may have hit it before and worked around it, likely be executing a subset of migrations to trigger creation of content types, then executing the rest of the migrations. Django could probably do better.
BTW: RunPython() is another thing, which can break your migrations, and should not be used (especially not by Django internally), because it relies on the application layer.
How else can you do a data migration? There is no `migrations.InsertIntoTable`, the only other way currently would be to run a `migrations.RunSql` query which may look different based on the database used.
Two things are wrong:
- automatic creation of content types
Why is it wrong to automatically create a content type? Content type is an opt-in feature since you can remove it from `INSTALLED_APPS`.
- creation of content types after running migrations
That’s the only real problem for me. Maybe using a signal for `migrations.CreateModel` (e.g. post_create_model), instead of using `post_migrate` would fix it, but there may be other scenarios I’m not thinking about.
Solution:
- creation of new app should add very first migration, which will add entry to the content types
How would you handle creating a model later on? Or if `django.contrib.contenttypes` is only added later on to `INSTALLED_APPS`?
Regards,
—
Arthur
--
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/0e4464f7-2ed7-4e6b-9b7e-f98a385dffd5%40googlegroups.com.
BTW: RunPython() is another thing, which can break your migrations, and should not be used (especially not by Django internally), because it relies on the application layer.
How else can you do a data migration? There is no `migrations.InsertIntoTable`,
the only other way currently would be to run a `migrations.RunSql` query which may look different based on the database used.
Two things are wrong:
- automatic creation of content types
Why is it wrong to automatically create a content type?
Content type is an opt-in feature since you can remove it from `INSTALLED_APPS`.
- creation of content types after running migrations
That’s the only real problem for me. Maybe using a signal for `migrations.CreateModel` (e.g. post_create_model), instead of using `post_migrate` would fix it, but there may be other scenarios I’m not thinking about.
Or if `django.contrib.contenttypes` is only added later on to `INSTALLED_APPS`?
After adding contrib.contenttypes, Django should check existence of django_content_type table. If exists, Django should only check for data changes and generate series of inserts/deletes. If not, Django should generate inserts for all models. If CT is removed later, Django should remove all CT data .
CT opt-in should be connected to a signal related to the creation of migration files (Autodetector?), not to a signal related to their execution. I.e. pre/post_autodection signals should be introduced.
Kind Regards,
Marcin
The problem is that data migration based on app layer (python objects, ie. Models and Managers here) will cause troubles after some time (when app is changing).In the other words - you cannot rely on your app layer when doing database changes. You should never do that, especially for projects requiring LTS.
In theory I understand the idea, but in practice, migrations, the ORM and the content type model are all part of Django and I don’t really see how the app changing could cause troubles. Do you have an example in mind?
Maybe "automatic" is not a proper word. They should be created automatically, but should be applied "at the right time".
Ok, that we agree on!
CT opt-in should be connected to a signal related to the creation of migration files (Autodetector?), not to a signal related to their execution. I.e. pre/post_autodection signals should be introduced.
I think we agree that the solution would be some sort of signal triggered when a model creation/deletion is detected (in the `makemigrations` phase as opposed to `migrate`) so that some code is added to the generated migration. The use of a signal is important to keep things decoupled and flexible.
The “some code is added to the migration” part still needs to be determined, either in the shape of insert/delete statements or a RunPython leveraging the ORM. In both cases, the values to insert (Adding a model) or to lookup for delete (Removing a model) are just 2 strings, the app label and the model class name.
After adding contrib.contenttypes, Django should check existence of django_content_type table. If exists, Django should only check for data changes and generate series of inserts/deletes. If not, Django should generate inserts for all models. If CT is removed later, Django should remove all CT data .
It’s a good idea but I don’t know offhand how we can keep migrations and content type decoupled to do that (especially the removal).
Finally, I also think the concept could be extended to the permission model which faces similar issues.
Regards
--
Arthur
--
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/af22034d-3983-4b19-87b2-256adc1cb11a%40googlegroups.com.
The problem is that data migration based on app layer (python objects, ie. Models and Managers here) will cause troubles after some time (when app is changing).In the other words - you cannot rely on your app layer when doing database changes. You should never do that, especially for projects requiring LTS.
In theory I understand the idea, but in practice, migrations, the ORM and the content type model are all part of Django and I don’t really see how the app changing could cause troubles. Do you have an example in mind?
Maybe "automatic" is not a proper word. They should be created automatically, but should be applied "at the right time".
Ok, that we agree on!
CT opt-in should be connected to a signal related to the creation of migration files (Autodetector?), not to a signal related to their execution. I.e. pre/post_autodection signals should be introduced.
I think we agree that the solution would be some sort of signal triggered when a model creation/deletion is detected (in the `makemigrations` phase as opposed to `migrate`) so that some code is added to the generated migration. The use of a signal is important to keep things decoupled and flexible.
The “some code is added to the migration” part still needs to be determined, either in the shape of insert/delete statements or a RunPython leveraging the ORM. In both cases, the values to insert (Adding a model) or to lookup for delete (Removing a model) are just 2 strings, the app label and the model class name.
After adding contrib.contenttypes, Django should check existence of django_content_type table. If exists, Django should only check for data changes and generate series of inserts/deletes. If not, Django should generate inserts for all models. If CT is removed later, Django should remove all CT data .
It’s a good idea but I don’t know offhand how we can keep migrations and content type decoupled to do that (especially the removal).
Finally, I also think the concept could be extended to the permission model which faces similar issues.
Regards
--
Arthur
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.