Opened 5 weeks ago

Closed 5 weeks ago

Last modified 5 weeks ago

#36565 closed New feature (wontfix)

Control column order in migrations

Reported by: Rinshan Owned by:
Component: Migrations Version: 5.2
Severity: Normal Keywords:
Cc: Rinshan Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When I add a new field in Django, the migration always puts the column at the end of the table.

Sometimes I need the column in a specific place (for example, to match a legacy database or schema).

Right now, the only way is to write custom SQL.

Can Django give an option to control column order in migrations, or keep the model field order?

Change History (3)

comment:1 by David Sanders, 5 weeks ago

Resolution: wontfix
Status: newclosed

Hi there,

No Django can't do this.

If you're looking for support pls see the Django forum or Discord where a community member may be able to help you out: https://docs.djangoproject.com/en/5.2/faq/help/ 👍

If you want to submit an idea for a feature in Django please check out the Django new features repo: https://github.com/django/new-features

comment:2 by Natalia Bidart, 5 weeks ago

Severity: Release blockerNormal

comment:3 by Simon Charette, 5 weeks ago

There exists another discussion about that (either on Trac or the django-dev mailing list) but I can't find it. IIRC the discussed points were

  1. Allowing re-ordering of fields would require the migration framework to ensure its ModelState.fields ordering is kept correctly. Today it's dict[str, Field] where order is not meaningful.
  2. It would require some shims on backends that don't support the MySQL specific ADD COLUMN AFTER syntax such as Postgres which would likely involve re-creating the table anyway. Not sure about Oracle but we rebuild the table on SQLite on column addition in most cases so it should be an issue in this case.

If your application has code that depends on column ordering it likely means that you have custom SQL anyway as the ORM abstracts that away entirely for you so using custom SQL through RunSQL or SeparateDatabaseAndState operation should not be a concern.

Note: See TracTickets for help on using tickets.
Back to Top