Re: Rethinking migrations

On Tue, Nov 8, 2016 at 12:34 PM, Patryk Zawadzki wrote: > I've just hit another problem related to custom fields. > > Currently migrations contain information about "rich" fields. If you use a > custom field type, the migration code will currently import your field type >

Re: Rethinking migrations

I've just hit another problem related to custom fields. Currently migrations contain information about "rich" fields. If you use a custom field type, the migration code will currently import your field type from its Python module. This is highly problematic in case either the code moves or you

Re: Rethinking migrations

> I assume that with a linear chain of migrations we'd only have to render model states when detecting database changes (makemigrations) and when executing RunPython code? Right, but I think it should be possible to prevent the rendering of model states in the autodetector. I'm planning to

Re: Rethinking migrations

niedz., 6.11.2016, 00:58 użytkownik charettes napisał: > I have to agree with Marteen. > > From my experience what really slow down the migrate and makemigrations > command is the rendering of model states into concrete model classes. This > is something I concluded from my

Re: Rethinking migrations

I have to agree with Marteen. >From my experience what really slow down the migrate and makemigrations command is the rendering of model states into concrete model classes. This is something I concluded from my work on adding the plan object to pre_migrate and post_migrate signals. As soon as

Re: Rethinking migrations

On Saturday, November 5, 2016 at 4:53:49 PM UTC+1, Patryk Zawadzki wrote: > > 1. Dependency resolution that turns the migration dependency graph into an > ordered list happens every time you try to create or execute a migration. > If you have several hundred migrations it becomes quite slow. I'm

Re: Rethinking migrations

W dniu sobota, 5 listopada 2016 19:57:38 UTC+1 użytkownik Aymeric Augustin napisał: > > My solution is to throw away and remake all migrations on a regular basis. > Then I `TRUNCATE TABLE django_migrations` and `django-admin migrate > --fake`. Obviously this isn’t a great solution. > > Since I

Re: Rethinking migrations

W dniu sobota, 5 listopada 2016 18:40:24 UTC+1 użytkownik Shai Berger napisał: > > > 2. Dependency resolution is only stable as long as the migration set is > > frozen. Sometimes introducing a new migration is enough to break > existing > > migrations by causing them to execute in a slightly

Re: Rethinking migrations

Hello, My solution is to throw away and remake all migrations on a regular basis. Then I `TRUNCATE TABLE django_migrations` and `django-admin migrate --fake`. Obviously this isn’t a great solution. Since I work mostly on small projects with just a couple developers on staff, doing this every

Re: Rethinking migrations

W dniu sobota, 5 listopada 2016 17:30:15 UTC+1 użytkownik Andrew Godwin napisał: > > Hello! I have opinions about this :) > > >> Possible solution (or "how I'd build it today if there was no existing >> code in Django core"): >> >> a. Make migrations part of the project and not individual

Re: Rethinking migrations

Hi, On Saturday 05 November 2016 17:53:49 Patryk Zawadzki wrote: > > I'm typing this from the comfort of Django: Under the Hood sprints so > please excuse poor grammar and the somewhat chaotic explanations that > follow. I'm very tired and English is not my mother tongue. This is not a > DEP but

Re: Rethinking migrations

Hello! I have opinions about this :) > Possible solution (or "how I'd build it today if there was no existing > code in Django core"): > > a. Make migrations part of the project and not individual apps. This takes > care of problem 3 above. > It also means it's impossible for apps to ship