charettes - Tue, 12 July 2022 at 13:11:14
> If you add fields to one your existing models the migration framework will
> add them at the end of your table as that's the most straightforward way of
> doing so. Of the top of my head only MySQL supports a syntax to add a
is it a correct takeaway, that while building an app and playing with
model fields left and right, before going live it's a good practice to
remove all migration files and let django recreate them and the DB?
in my understanding that will recreate the tables with a column order
closer to model fields order (plus reduce the number of migration
files), while flattening the migrations probably keeps the previous order?
> models that have a different field layout than their table. The migration
> framework also doesn't have any notion of field ordering right now so that
> would also be work that needs to be done.
i think the current situation is a kind of sweet spot where there is
room for a bit of manual "optimisation" by ordering the fields.
going web-scale will need more consideration by those lucky ones :}
> I'm of opinion that if you are experiencing performance issues due to the
> physical layout of a particular table managed by Django you're likely
> better off not relying on the automatically generated migrations that
> Django provides and use a mix of `RunSQL` and `SeparateDatabaseAndState` to
> achieve what you're after.
i think it's more about wasted disk space than raw performance (although
one is related to the other).
thank you for the indepth answer.
--
-f