[Django] #25133: Changing a PositiveIntegerField to an IntegerField does not remove >=0 check in migration
Django
check in migration
----------------------------+----------------------------------
Reporter: jproffitt | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7
Severity: Normal | Keywords: migrations, postgres
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------+----------------------------------
When you change a `PositiveIntegerField` to just an `IntegerField`, the
>=0 database check in postgres is not removed when running the migration.
Initial migration:
{{{
('year', models.PositiveIntegerField(blank=True, null=True,)),
}}}
Alter migration:
{{{
migrations.AlterField(
model_name='art',
name='year',
field=models.IntegerField(blank=True, null=True),
preserve_default=True,
),
}}}
I'm left with having to do a `RunSQL` operation to remove the constraint.
--
Ticket URL: <https://code.djangoproject.com/ticket/25133>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
check in migration
Reporter: jproffitt | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.7
Severity: Normal | Resolution:
| worksforme
Keywords: migrations, | Triage Stage:
postgres | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by charettes):
* status: new => closed
* needs_docs: => 0
* resolution: => worksforme
* needs_tests: => 0
* needs_better_patch: => 0
Comment:
I cannot reproduce with the latest 1.7.x release (1.7.9) on PostgreSQL.
Can you provide more details?
--
Ticket URL: <https://code.djangoproject.com/ticket/25133#comment:1>
Django
check in migration
Reporter: jproffitt | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: migrations, | Triage Stage:
postgres | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by jproffitt):
* status: closed => new
* version: 1.7 => 1.8
* resolution: worksforme =>
Comment:
Sorry, I never knew someone responded. I am still having this issue. I am
using django 1.8.4 now. Here are the steps to reproduce:
1. Create a model with a `PositiveIntegerField`:
{{{
class MyModel(models.Model):
an_integer = models.PositiveIntegerField(null=True, blank=True)
}}}
2: create migrations, and you get this migration:
{{{
class Migration(migrations.Migration):
dependencies = [
]
operations = [
migrations.CreateModel(
name='MyModel',
fields=[
('id', models.AutoField(verbose_name='ID',
serialize=False, auto_created=True, primary_key=True)),
('an_integer', models.PositiveIntegerField(null=True,
blank=True)),
],
),
]
}}}
which generates this constraint in Postgres:
{{{
ALTER TABLE myproject.myapp_mymodel
ADD CONSTRAINT myapp_mymodel_an_integer_check CHECK (an_integer >= 0);
}}}
3. Change the `PositiveIntegerField` to a plain `IntegerField`:
{{{
class MyModel(models.Model):
an_integer = models.IntegerField(null=True, blank=True)
}}}
4. Make migrations again, and you get this migration:
{{{
class Migration(migrations.Migration):
dependencies = [
('myapp', '0001_initial'),
]
operations = [
migrations.AlterField(
model_name='mymodel',
name='an_integer',
field=models.IntegerField(null=True, blank=True),
),
]
}}}
But the constraint is still there in the database. To check, I can try to
create a record with a negative integer:
{{{
>>> from myapp.models import MyModel
>>> MyModel.objects.create(an_integer=-5)
...
IntegrityError: new row for relation "myapp_mymodel" violates check
constraint "myapp_mymodel_an_integer_check"
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25133#comment:2>
Django
check in migration
Reporter: jproffitt | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.8
Severity: Normal | Resolution: needsinfo
Keywords: migrations, | Triage Stage:
postgres | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by charettes):
* cc: charettes, jproffitt (added)
* status: new => closed
* resolution: => needsinfo
Comment:
Hi jproffitt,
I still can't reproduce on Python 2.7 with Django 1.8.4.
The constraint is effectively dropped if I run your exact testcase in
isolation. Here's the output of `sqlmigrate` for the two migrations.
`0001_initial`
{{{#!sql
BEGIN;
CREATE TABLE "ticket_25133_foo" ("id" serial NOT NULL PRIMARY KEY, "num"
integer NULL CHECK ("num" >= 0));
COMMIT;
}}}
`0002_auto_...`
{{{#!sql
BEGIN;
ALTER TABLE "ticket_25133_foo" DROP CONSTRAINT
"ticket_25133_foo_num_6f290808d3aecee4_check";
COMMIT;
}}}
What does `sqlmigrate` yield for your second migration?
--
Ticket URL: <https://code.djangoproject.com/ticket/25133#comment:3>
Django
check in migration
Reporter: jproffitt | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.8
Severity: Normal | Resolution: needsinfo
Keywords: migrations, | Triage Stage:
postgres | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by jproffitt):
That is strange. I guess its something I am doing wrong then. `sqlmigrate`
for 0002 yields nothing for me. I am using a custom `SCHEMA` in postgres
if that makes any difference.
Here are the relevant versions I am using:
python 2.7.9
django 1.8.4
psycopg2 2.6.1
--
Ticket URL: <https://code.djangoproject.com/ticket/25133#comment:4>
Django
check in migration
Reporter: jproffitt | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.8
Severity: Normal | Resolution: needsinfo
Keywords: migrations, | Triage Stage:
postgres | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by charettes):
Custom `SCHEMA` are not yet supported so it makes a big difference, see
#6148 which you should be aware of at this point.
If I remember correctly constraints retrieval is only done against the
public schema which might be why you're having trouble here.
--
Ticket URL: <https://code.djangoproject.com/ticket/25133#comment:5>
Django
check in migration
Reporter: jproffitt | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.8
Severity: Normal | Resolution: needsinfo
Keywords: migrations, | Triage Stage:
postgres | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by jproffitt):
Oh wow. Thats probably it then. I didn't know that wasn't supported. We've
been using custom `SCHEMA`s for years. I've never noticed any issues until
now. I assumed that setting `'SCHEMA'` in the `DATABASES` setting would
just work. Now I can even see that that is not even documented!
--
Ticket URL: <https://code.djangoproject.com/ticket/25133#comment:6>
Django
check in migration
Reporter: jproffitt | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.8
Severity: Normal | Resolution: needsinfo
Keywords: migrations, | Triage Stage:
postgres | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by charettes):
I never knew this option even existed, I assumed you were setting a
`search_path` on [https://docs.djangoproject.com/en/1.8/ref/signals
/#connection-created connection_created].
After
[https://github.com/django/django/blob/a51070e7434426467869147608c5a8ca58e21e00/django/db/backends/postgresql/introspection.py#L139-L163
verification] It looks like were really just retrieving constraints
defined in the `public` schema.
--
Ticket URL: <https://code.djangoproject.com/ticket/25133#comment:7>
Django
check in migration
Reporter: jproffitt | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.8
Severity: Normal | Resolution: needsinfo
Keywords: migrations, | Triage Stage:
postgres | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by jproffitt):
Well it turns out that option doesn't even exist! I guess it was just
wishful thinking on our part. Would be nice if that was supported though.
--
Ticket URL: <https://code.djangoproject.com/ticket/25133#comment:8>