{{{
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.
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>
* type: Uncategorized => Bug
* component: Uncategorized => Database layer (models, ORM)
--
Ticket URL: <https://code.djangoproject.com/ticket/29486#comment:2>
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>
* component: Database layer (models, ORM) => Migrations
--
Ticket URL: <https://code.djangoproject.com/ticket/29486#comment:4>
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>
* 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>