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
>
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
> 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
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
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
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
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
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
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
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
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
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
Greetings, Jazz Guitarists,
I've briefly talked about this with Markus and he mentioned that the
subject was already brought up by Tyson Clugg but I think it deserves a
proper discussion here.
I'm typing this from the comfort of Django: Under the Hood sprints so
please excuse poor grammar and
13 matches
Mail list logo