[Django] #36565: Control column order in migrations

[Django]

#36565: Control column order in migrations
-------------------------+-------------------------------------------
Reporter: Rinshan | Type: New feature
Status: new | Component: Migrations
Version: 5.2 | Severity: Release blocker
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------+-------------------------------------------
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/36565>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#36565: Control column order in migrations

---------------------------------+--------------------------------------
Reporter: Rinshan | Owner: (none)
Type: New feature | Status: closed
Component: Migrations | Version: 5.2
Severity: Release blocker | Resolution: wontfix

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0

---------------------------------+--------------------------------------
Changes (by David Sanders):

* resolution: => wontfix
* status: new => closed

Comment:

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
--
Ticket URL: <https://code.djangoproject.com/ticket/36565#comment:1>

[Django]

#36565: Control column order in migrations
-----------------------------+--------------------------------------
Reporter: Rinshan | Owner: (none)
Type: New feature | Status: closed
Component: Migrations | Version: 5.2

Severity: Normal | Resolution: wontfix

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0

-----------------------------+--------------------------------------
Changes (by Natalia Bidart):

* severity: Release blocker => Normal

--
Ticket URL: <https://code.djangoproject.com/ticket/36565#comment:2>

[Django]

#36565: Control column order in migrations
-----------------------------+--------------------------------------
Reporter: Rinshan | Owner: (none)
Type: New feature | Status: closed
Component: Migrations | Version: 5.2
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+--------------------------------------

Comment (by Simon Charette):

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
[https://dev.mysql.com/doc/refman/8.0/en/alter-table.html#alter-table-add-
drop-column MySQL specific] `ADD COLUMN AFTER` syntax such
[https://wiki.postgresql.org/wiki/Alter_column_position 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/36565#comment:3>