Re: Content types shouldn't be created on post_migrate signal

2018-10-13 Thread Petter Strandmark
I encountered a similar issue recently, but with auth permissions. It is described here: https://code.djangoproject.com/ticket/29843 On Wednesday, October 3, 2018 at 1:01:37 PM UTC+2, Marcin Nowak wrote: > > Hello. > > There is a huge issue with content types framework. The data is loaded >

Re: Content types shouldn't be created on post_migrate signal

2018-10-07 Thread Arthur Rio
Hey Marcin, I hope you had a good week-end. After looking through the codebase to get more familiar with how `pre_migrate` and `post_migrate` are currently used, I thought we could simply have the same sort of signal for `post_makemigrations`, where a third party could get a list of the

Re: Content types shouldn't be created on post_migrate signal

2018-10-05 Thread Arthur Rio
For some reason the text is white… Here it is in black: Hey 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

Re: Content types shouldn't be created on post_migrate signal

2018-10-05 Thread Arthur Rio
Hey 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

Re: Content types shouldn't be created on post_migrate signal

2018-10-04 Thread Marcin Nowak
Hi Arthur. 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`, > You're right. That's

Re: Content types shouldn't be created on post_migrate signal

2018-10-04 Thread Arthur Rio
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

Re: Content types shouldn't be created on post_migrate signal

2018-10-04 Thread Marcin Nowak
Hi Aymeric. Thank you for your reply. Unfortunately you wrote mostly about me or my writing style, not about the issue. I disagree with your opinion about my comments being passive or aggressive. I'm always writing about a piece of code, functionality, design/architecture or bug. I never

Re: Content types shouldn't be created on post_migrate signal

2018-10-04 Thread Aymeric Augustin
Hello Marcin, I assume you're writing to this list because you would like other Django contributors to cooperate in order to fix this issue. 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

Re: Content types shouldn't be created on post_migrate signal

2018-10-03 Thread Marcin Nowak
] > > 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? > > Thanks, but as a workaround you can do almost everything. My post is about proposal of fixing the issue. BTW: RunPython() is

Re: Content types shouldn't be created on post_migrate signal

2018-10-03 Thread Adam Johnson
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? On Wed, 3 Oct 2018 at 12:01, Marcin Nowak wrote: > Hello. > > There is a huge issue with content types framework. The data is loaded >

Content types shouldn't be created on post_migrate signal

2018-10-03 Thread Marcin Nowak
Hello. There is a huge issue with content types framework. The data is loaded after every migration (post_migrate signal) automatically, and this approach is against db data consistency. The biggest problem is with data migrations, which are applied at the first time (on clean database). Any