#29787: ForeignKey to User with BigIntegerField id/pk gets created as 'integer'
instead of 'bigint' field in postgres
-------------------------------------+-------------------------------------
Reporter: Andrew Badr | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 1.11
(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
-------------------------------------+-------------------------------------
Description changed by Andrew Badr:
Old description:
> I ran into this bug when upgrading from 1.10 to 1.11. Doing a git bisect
> tracked it down to the 1.11.7->1.11.8 change, and specifically
> b8a2f3c2d66aa15af4be745a576609b958a853c0 is the first bad commit (fix for
> #28305).
>
> My test case creates a User model instance, then creates another model
> instance pointing to it via ForeignKey. On 1.11.7, this works fine, and
> inspecting the database shows the fk field as having type 'bigint' in
> postgres. On 1.11.8, the test fails, and inspecting the db shows the
> field as a regular 'integer'.
>
> I tried to repro with a minimal test case on a fresh project, but sadly
> was not able to recreate the bug. (It worked fine.) So there must be some
> other config in my project that's affecting this. If I have time I'll try
> to pin it down (already spent 2 hours on this), but maybe someone who
> worked on that patch can make an educated guess on what's happening?
New description:
I ran into this bug when upgrading from 1.10 to 1.11. My test case creates
a User model instance, then creates another model instance pointing to it
via ForeignKey. On 1.10, this works fine, and inspecting the database
shows the fk field as having type 'bigint' in postgres. On 1.11, the test
fails, and inspecting the db shows the field as a regular 'integer'.
After some digging, I've found that this bug happens, oddly, at different
commits for different models. For some models (??) it occurs starting in
45ded053b1f4320284aa5dac63052f6d1baefea9 (#27666). For others,
b8a2f3c2d66aa15af4be745a576609b958a853c0 is the first bad commit (fix for
#28305; comes between 1.11.7 and 1.11.8). The fact that the former has to
do with migrations might be a clue.
I tried to repro with a minimal test case on a fresh project, but sadly
was not able to recreate the bug. (It worked fine.) So there must be some
other config in my project that's affecting this. If I have time I'll try
to pin it down (already spent ~4 hours on this), but maybe someone who
worked on the relevant patches can make an educated guess on what's
happening?
--
--
Ticket URL: <https://code.djangoproject.com/ticket/29787#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.5b98e48b2016aaa0b2a3eaebcc057be2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
