The (same) constraint drop/create is a blocking operation for PostgreSQL,
so it is an undesirable and unexpected behavior.
--
Ticket URL: <https://code.djangoproject.com/ticket/31826>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Comment (by Iuri de Silvio):
I sent a pull request here. https://github.com/django/django/pull/13237
--
Ticket URL: <https://code.djangoproject.com/ticket/31826#comment:1>
* owner: nobody => Iuri de Silvio
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/31826#comment:2>
Old description:
> When I change: `pink = models.Integer(default=0)` to `pink =
> models.Integer(default=0, db_column="pink")` the migration can recreate
> constraints if it is an FK or even reconstruct the table (SQLite).
>
> The (same) constraint drop/create is a blocking operation for PostgreSQL,
> so it is an undesirable and unexpected behavior.
New description:
When I change: `pink = models.Integer(default=0)` to `pink =
models.Integer(default=0, db_column="pink")` the migration recreate
constraints if it is an FK or even reconstruct the table (SQLite), but
nothing really changed.
The (same) constraint drop/create is a blocking operation for PostgreSQL,
so it is an undesirable and unexpected behavior.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/31826#comment:3>
Old description:
> When I change: `pink = models.Integer(default=0)` to `pink =
> models.Integer(default=0, db_column="pink")` the migration recreate
> constraints if it is an FK or even reconstruct the table (SQLite), but
> nothing really changed.
>
> The (same) constraint drop/create is a blocking operation for PostgreSQL,
> so it is an undesirable and unexpected behavior.
New description:
When I change `pink = models.Integer(default=0)` to `pink =
models.Integer(default=0, db_column="pink")` the migration drop/create the
same constraints when it is an FK or even reconstruct the table (SQLite),
but nothing really changed. The constraint drop/create is a blocking
operation for PostgreSQL, so it is an undesirable and unexpected behavior.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/31826#comment:4>
* version: 3.0 => master
--
Ticket URL: <https://code.djangoproject.com/ticket/31826#comment:5>
* cc: Simon Charette (added)
* has_patch: 0 => 1
* stage: Unreviewed => Accepted
Comment:
Thanks. See related ticket when
[https://code.djangoproject.com/ticket/29245#comment:1 Simon pointed out]
that such change should be a noop.
--
Ticket URL: <https://code.djangoproject.com/ticket/31826#comment:6>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/31826#comment:7>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/31826#comment:8>
* needs_better_patch: 0 => 1
Comment:
Patch needs improvement because it depends on #31825 merge and then I'll
fix conflicts.
--
Ticket URL: <https://code.djangoproject.com/ticket/31826#comment:9>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/31826#comment:10>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/31826#comment:11>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"632ccffc49658de5348c51a8918719364be54f37" 632ccffc]:
{{{
#!CommitTicketReference repository=""
revision="632ccffc49658de5348c51a8918719364be54f37"
Fixed #31826 -- Made AlterField operation a noop when adding db_column.
AlterField operation with adding a db_column is a noop if the column
name is not changed.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/31826#comment:12>