[Django] #18174: Model inheritance pointers doesn't refer to parent to refer to grandparents
Django
----------------------------------------------+--------------------
Reporter: phowe | Owner: nobody
Type: Bug | Status: new
Component: Database layer (models, ORM) | Version: 1.4
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------------------+--------------------
I Create the Following Models:
{{{
class Base1( models.Model ):
b1_id = models.AutoField( primary_key=True )
b1_desc = models.CharField( max_length=100 )
class Base2( models.Model ):
b2_id = models.AutoField( primary_key=True )
b2_desc = models.CharField( max_length=100 )
class Base3( models.Model ):
b3_id = models.AutoField( primary_key=True )
b3_desc = models.CharField( max_length=100 )
class Middle( Base1, Base2, Base3 ):
m_desc = models.CharField( max_length=100 )
class Top( Middle ):
t_desc = models.CharField( max_length=100 )
}}}
I run this:
{{{
d = Top1.objects.all()
print d.query
}}}
I get:
{{{
SELECT "Test_base1"."b1_id", "Test_base1"."b1_desc", "Test_base2"."b2_id",
"Test_base2"."b2_desc", "Test_base3"."b3_id", "Test_base3"."b3_desc",
"Test_middle"."base3_ptr_id", "Test_middle"."base2_ptr_id",
"Test_middle"."base1_ptr_id", "Test_middle"."m_desc",
"Test_top1"."middle_ptr_id", "Test_top1"."t1_desc"
FROM "Test_top1"
INNER JOIN "Test_base1" ON ("Test_top1"."middle_ptr_id" =
"Test_base1"."b1_id")
INNER JOIN "Test_base2" ON ("Test_top1"."middle_ptr_id" =
"Test_base2"."b2_id")
INNER JOIN "Test_base3" ON ("Test_top1"."middle_ptr_id" =
"Test_base3"."b3_id")
INNER JOIN "Test_middle" ON ("Test_top1"."middle_ptr_id" =
"Test_middle"."base1_ptr_id")
}}}
It refers the top object directly to the base objects. I would expect:
{{{
FROM "Test_top1"
INNER JOIN "Test_middle" ON ("Test_top1"."middle_ptr_id" =
"Test_middle"."base1_ptr_id")
INNER JOIN "Test_base1" ON ("Test_middle"."base1_ptr_id" =
"Test_base1"."b1_id")
INNER JOIN "Test_base2" ON ("Test_middle"."base2_ptr_id" =
"Test_base2"."b2_id")
INNER JOIN "Test_base3" ON ("Test_middle"."base3_ptr_id" =
"Test_base3"."b3_id")
}}}
This would normally not be a problem, however if I create a Top2 object or
a Middle, now the ptr_ids will not all be incrementing at the same rate.
--
Ticket URL: <https://code.djangoproject.com/ticket/18174>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: phowe | Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version: 1.4
(models, ORM) | Resolution: invalid
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Changes (by andrewgodwin):
* status: new => closed
* needs_better_patch: => 0
* resolution: => invalid
* needs_tests: => 0
* needs_docs: => 0
Comment:
Are you sure the ptr_ids are going to increment at "different rates"?
Those two queries are functionally equivalent - since ptr_id is always the
same across all objects - and only the base class will define the PK value
used for a new object.
I'm closing this as invalid - it needs a code/console example on what
exactly the problem is with IDs before I can understand what the problem
is supposed to be.
--
Ticket URL: <https://code.djangoproject.com/ticket/18174#comment:1>
Django
Reporter: phowe | Owner: nobody
Type: Bug | Status: reopened
(models, ORM) | Resolution:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Changes (by phowe):
* status: closed => reopened
* resolution: invalid =>
Comment:
Here is an Example model and unit test to demonstrate the issue
models.py
{{{
from django.db import models
class Base1( models.Model ):
b1_id = models.AutoField( primary_key=True )
b1_desc = models.CharField( max_length=100 )
class Base2( models.Model ):
b2_id = models.AutoField( primary_key=True )
b2_desc = models.CharField( max_length=100 )
class Middle1( Base1, Base2 ):
m1_desc = models.CharField( max_length=100 )
class Middle2( Base2 ):
m2_desc = models.CharField( max_length=100 )
class Top1( Middle1 ):
t1_desc = models.CharField( max_length=100 )
class Top2( Middle2 ):
t2_desc = models.CharField( max_length=100 )
}}}
test.py
{{{
from django.test import TestCase
from demo.demoapp.models import *
class DemoAppTests( TestCase ):
def top1_only( self ):
tmp = Top1()
tmp.b1_desc = 'b1 1'
tmp.b2_desc = 'b2 1'
tmp.m1_desc = 'm1 1'
tmp.t1_desc = 't1 1'
tmp.save()
tmp = Top2()
tmp.b2_desc = 'b2 2'
tmp.m2_desc = 'm2 2'
tmp.t2_desc = 't2 2'
tmp.save()
tmp = Top1()
tmp.b1_desc = 'b1 3'
tmp.b2_desc = 'b2 3'
tmp.m1_desc = 'm1 3'
tmp.t1_desc = 't1 3'
tmp.save()
tmp = Top1.objects.get( b1_desc='b1 1' )
print '%s %s %s %s' % ( tmp.b1_desc, tmp.b2_desc, tmp.m1_desc,
tmp.t1_desc )
tmp = Top2.objects.get( b2_desc='b2 2' )
print '%s %s %s' % ( tmp.b2_desc, tmp.m2_desc, tmp.t2_desc )
tmp = Top1.objects.get( b1_desc='b1 3' )
print '%s %s %s %s' % ( tmp.b1_desc, tmp.b2_desc, tmp.m1_desc,
tmp.t1_desc )
self.failUnlessEqual( tmp.b1_desc, 'b2 3' )
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/18174#comment:2>
Django
Reporter: phowe | Owner: nobody
Component: Database layer | Version: 1.4
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Comment (by phowe):
Replying to [comment:2 phowe]:
> Here is an Example model and unit test to demonstrate the issue
>
The output is:
b1 1 b2 1 m1 1 t1 1
b2 2 m2 2 t2 2
b1 3 b2 '''2''' m1 3 t1 3
it should be
b1 1 b2 1 m1 1 t1 1
b2 2 m2 2 t2 2
b1 3 b2 '''3''' m1 3 t1 3
--
Ticket URL: <https://code.djangoproject.com/ticket/18174#comment:3>
Django
Reporter: phowe | Owner: nobody
Component: Database layer | Version: 1.4
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Comment (by phowe):
Replying to [comment:3 phowe]:
> Replying to [comment:2 phowe]:
Sorry for the bad formmating, trying again.
The output is:[[BR]]
b1 1 b2 1 m1 1 t1 1[[BR]]
b2 2 m2 2 t2 2[[BR]]
b1 3 b2 '''2''' m1 3 t1 3[[BR]]
[[BR]]
it should be:[[BR]]
b1 1 b2 1 m1 1 t1 1[[BR]]
b2 2 m2 2 t2 2[[BR]]
b1 3 b2 '''3''' m1 3 t1 3[[BR]]
--
Ticket URL: <https://code.djangoproject.com/ticket/18174#comment:4>
Django
Reporter: phowe | Owner: nobody
Component: Database layer | Version: 1.4
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Changes (by msopacua):
* cc: msopacua (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/18174#comment:5>
Django
Reporter: phowe | Owner: nobody
Component: Database layer | Version: 1.4
(models, ORM) | Resolution:
Keywords: | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by akaariai):
* stage: Unreviewed => Accepted
Comment:
Verified the issue, and added a patch containing tests for this.
--
Ticket URL: <https://code.djangoproject.com/ticket/18174#comment:6>
Django
Reporter: phowe | Owner: nobody
Component: Database layer | Version: 1.4
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
* has_patch: 0 => 1
Comment:
This patch seems to satisfy the unit test. The patch includes the test,
and also includes an extra test to make sure all the ancestors are joined
in. I added another parameter to get_ancestor_link in options.py. I
noticed that the only other place it is used is
django/contrib/gis/db/models/sql/compiler.py, I don't know if that code
also needs to be updated to handle grandparent joining correctly or not.
--
Ticket URL: <https://code.djangoproject.com/ticket/18174#comment:7>
Django
Reporter: phowe | Owner: nobody
Type: Bug | Status: reopened
Component: Database layer | Version: 1.4
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by pnhowe):
Any word if this patch will be considered and Merged?
--
Ticket URL: <https://code.djangoproject.com/ticket/18174#comment:8>
Django
Reporter: phowe | Owner: nobody
Type: Bug | Status: reopened
Component: Database layer | Version: 1.4
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by carljm):
Replying to [comment:8 pnhowe]:
> Any word if this patch will be considered and Merged?
The next step here is for someone other than the patch author to review
the patch and try it out. If they think the code looks ok, and can verify
that it solves the problem and all tests pass, they can mark it Ready For
Checkin and that will help bring it to the attention of a core developer
for commit. Feel free to recruit someone to do that if you want to move
things along!
--
Ticket URL: <https://code.djangoproject.com/ticket/18174#comment:9>
Django
Reporter: phowe | Owner: nobody
Type: Bug | Status: new
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by pyriku):
I just checked and the patch doesn't apply now as some tests got moved
from tests/regressiontests/queries to tests/queries
--
Ticket URL: <https://code.djangoproject.com/ticket/18174#comment:11>
Django
Reporter: phowe | Owner: nobody
Type: Bug | Status: new
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/18174#comment:12>
Django
Reporter: phowe | Owner: nobody
Type: Bug | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
According to a comment on #17695, this patch fixes that issue so I marked
it as a duplicate.
--
Ticket URL: <https://code.djangoproject.com/ticket/18174#comment:13>
Django
Reporter: phowe | Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version: 1.4
(models, ORM) |
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Changes (by Baptiste Mispelon):
* status: new => closed
* resolution: => fixed
Comment:
I believe this god fixed but it's hard to pinpoint exactly what commit did
it.
Using the provided testcase from comment:6, I was able to bisect but it
seems that the issue got fixed in two separate steps. Here's a rough
timeline:
0) (this issue is reported). Django is at 1.4 and the testcase fails with
something like `AssertionError: u'appname_top' != 'appname_middle'`.
1) Enters commit 68985db48212c701a3d975636123a5d79bdc006f (part of the 1.6
release which changes the error: `OperationalError: no such column:
appname_middle.b2_id`
2) Finally with commit 38e24d680d28b92997def9ab46a961d09bb81dce (1.7
release), the testcase passes.
The test added with 38e24d680d28b92997def9ab46a961d09bb81dce is not
exactly the same as the one attached to this ticket but I'm pretty
confident that they're similar enough:
* Both involve a 3-step inheritance chain with multiple inheritance in the
middle model.
* Both test raise the same error prior to the fix (`OperationalError: no
such column: appname_middle.b2_id`)
Therefore I think this ticket can be marked as fixed.
--
Ticket URL: <https://code.djangoproject.com/ticket/18174#comment:14>