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 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/Ys7ArlS5VttSFSA9%40obiit.org.
