4 ms·
> At the end of the day the migrations framework is just a SQL dependency graph. It's not quite. During operation it actually mutates an in-memory shadow of yo
by ris 6y ago
> At the end of the day the migrations framework is just a SQL dependency graph.
It's not quite. During operation it actually mutates an in-memory shadow of your model structure. And that's really clever, but if you've got a large set of models it can be really slow.
- orf 6y agoThat's built on top of the dependency graph though. You can use it without any models - just a bunch of inter-dependent `RunSQL` statements across different apps in your project.
- dvarrazzo 6y agoIt also breaks in interesting way: I discovered just today that constants defined on the Model subclass are not available when you use 'get_model()'. I suspect methods wouldn't be accessible either?
- MythicDev 6y agoAs far as I know, this is by design; your migrations are supposed to operate on a frozen state of what your models and code _were at a point in time_. If you would rely on code outside of said migration, you would be breaching that frozen state and potentially end up with unintended side-effects (e.g. running a migration created 2 years ago that imports your code that changed today). This is why you might have to sometimes copy-paste logic to your python migrations, but you also guarantee that the migration always runs the same way.
- aeyes 6y agoIf it gets too slow you can always squash migrations. But since Django 2 I haven't seen the need to do it, runs in a few seconds even with hundreds of migrations.