[Django] #29486: Odd behaviour with ForeignKey to non-integer field since Django 2.0.5 with PostgreSQL
Django
PostgreSQL
------------------------------------------+------------------------
Reporter: HenrikOssipoff | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 2.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------+------------------------
I was upgrading one of our projects from 1.11.x to the newest Django 2.0.x
when encountering a rather odd thing - all of our tests were literally
failing with seemingly a database error:
{{{
django.db.utils.DataError: value "1111222233334444" is out of range for
type integer
}}}
The field, however, is not an integer field, but rather a char field - so
that particular string shouldn't be of any problem - and the fact that it
appears to report back being an integer field is rather bizarre.
While I know that this error returned is simply a psycopg2.DataError in
disguise, it turns out that this error seem to have been introduced in
2.0.5 specifically - all of our tests passes in 2.0.4.
The slight problem here is that I've been unable to reproduce a minimal
working example that can reproduce the error, even though it's really
consistent for us.
Our models look something like this (simplified):
{{{
class Giftcard(Model):
STATUS_CREATED = 'CREATED'
STATUS_ACTIVATED = 'ACTIVATED'
STATUS_SUSPENDED = 'SUSPENDED'
STATUS_EXPIRED = 'EXPIRED'
STATUS_CLOSED = 'CLOSED'
STATUS_CHOICE = (
(STATUS_CREATED, 'Created'),
(STATUS_ACTIVATED, 'Activated'),
(STATUS_SUSPENDED, 'Suspended'),
(STATUS_EXPIRED, 'Expired'),
(STATUS_CLOSED, 'Closed'),
)
code = models.CharField(max_length=16, primary_key=True)
status = models.CharField(max_length=20, choices=STATUS_CHOICE,
default=STATUS_CREATED, db_index=True)
def status_change(self, reason, to):
StatusChangeLog.objects.create(giftcard=self, reason=reason,
from_status=self.status, to_status=to)
class StatusChangeLog(Model):
giftcard = models.ForeignKey('giftcards.Giftcard',
related_name='status_logs', on_delete=models.PROTECT)
reason = models.TextField(blank=True, default='')
from_status = models.CharField(max_length=20,
choices=Giftcard.STATUS_CHOICE)
to_status = models.CharField(max_length=20,
choices=Giftcard.STATUS_CHOICE)
}}}
When the Giftcard model is instantiated with a code of "1111222233334444"
(as a string), saved, and then the status_change method is called, the
above exception occurs.
I've been through some of code that went into 2.0.5, but I'm not well
enough into the inner workings of Django know exactly what caused this - I
just know that this behaviour wasn't in 1.11.x, and also wasn't in 2.0.4.
--
Ticket URL: <https://code.djangoproject.com/ticket/29486>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
PostgreSQL
Reporter: Henrik Ossipoff | Owner: nobody
Hansen |
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 2.0
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 Alexander Tatarinov):
Cannot reproduce at 2.0.5 with PostgreSQL.Try to bisect to find the commit
at which tests starts to fail.
--
Ticket URL: <https://code.djangoproject.com/ticket/29486#comment:1>
Django
PostgreSQL
Reporter: Henrik Ossipoff | Owner: nobody
Hansen |
Component: Database layer | Version: 2.0
(models, ORM) |
Severity: Normal | Resolution:
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 Alexander Tatarinov):
* type: Uncategorized => Bug
* component: Uncategorized => Database layer (models, ORM)
--
Ticket URL: <https://code.djangoproject.com/ticket/29486#comment:2>
Django
PostgreSQL
Reporter: Henrik Ossipoff | Owner: nobody
Hansen |
Type: Bug | Status: new
Component: Database layer | Version: 2.0
(models, ORM) |
Severity: Normal | Resolution:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Henrik Ossipoff Hansen):
I've bisected the commit to be
[https://github.com/django/django/commit/d5018abf1c4e3c68f1a825d05eb9035325707e16
d5018abf1c4e3c68f1a825d05eb9035325707e16]
I'm not entirely sure why this commit in particular is causing problems
though - and I'm a bit puzzled that we're unable to reproduce it with a
"clean" model. Could this mean it's related to applying the migration
history during our unit tests?
I suppose I could try to get together a working test set tomorrow.
--
Ticket URL: <https://code.djangoproject.com/ticket/29486#comment:3>
Django
PostgreSQL
Reporter: Henrik Ossipoff | Owner: nobody
Hansen |
Type: Bug | Status: new
Severity: Normal | Resolution:
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 Alexander Tatarinov):
* component: Database layer (models, ORM) => Migrations
--
Ticket URL: <https://code.djangoproject.com/ticket/29486#comment:4>
Django
PostgreSQL
Reporter: Henrik Ossipoff | Owner: nobody
Hansen |
Type: Bug | Status: new
Component: Migrations | Version: 2.0
Severity: Normal | Resolution:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham):
Yes, it looks like it's related to migrations and an `AlterField`
operation.
--
Ticket URL: <https://code.djangoproject.com/ticket/29486#comment:5>
Django
PostgreSQL
Reporter: Henrik Ossipoff | Owner: nobody
Hansen |
Component: Migrations | Version: 2.0
Severity: Normal | Resolution: needsinfo
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 Tim Graham):
* status: new => closed
* resolution: => needsinfo
Comment:
Please reopen when you provide a sample project and confirm that Django is
at fault.
--
Ticket URL: <https://code.djangoproject.com/ticket/29486#comment:6>