Ticket #8161 - Please help me fix this.

3 views
Skip to first unread message

Madhusudan C.S

unread,
Mar 11, 2009, 11:31:32 AM3/11/09
to Django developers
Hi all,
     I wanted to fix this bug. I just went through the code to see what was happening. For the same sample code given in the ticket, these were my findings:

The schema generated looks like this and there is no issue with it:
CREATE TABLE "testapp_childmodel" (
    "parentmodel_ptr_id" integer NOT NULL PRIMARY KEY REFERENCES "testapp_parentmodel" ("id"),
    "text" text NOT NULL
);
CREATE TABLE "testapp_parentmodel" (
    "id" integer NOT NULL PRIMARY KEY,
    "slug" varchar(50) NOT NULL
);
CREATE TABLE "testapp_parentmodel_links" (
    "id" integer NOT NULL PRIMARY KEY,
    "from_parentmodel_id" integer NOT NULL REFERENCES "testapp_parentmodel" ("id"),
    "to_parentmodel_id" integer NOT NULL REFERENCES "testapp_parentmodel" ("id"),
    UNIQUE ("from_parentmodel_id", "to_parentmodel_id")
);

CREATE INDEX "testapp_parentmodel_slug" ON "testapp_parentmodel" ("slug");

I inserted test1, test2 and test3(all names being values of slug field) to ParentModel and linked test1 and test3 to test2 through links field. There seems to be no issues. Then I inserted testc1, testc2 and testc3 to ChildModel and linked testc2 and testc3 to testc1 through inherited links field. Now I can see only to links, i.e
I get these results in the interactive interpreter:

>>> from dummy.testapp.models import ParentModel, ChildModel
>>> c1 = ChildModel.objects.get(slug='testc1')
>>> c2 = ChildModel.objects.get(slug='testc2')
>>> c3 = ChildModel.objects.get(slug='testc3')
>>> c1.links.all()
[]
>>> c2.links.all()
[<ParentModel: testc1>]
>>> c3.links.all()
[<ParentModel: testc1>]

This means only to links are being queried and not from links for the inherited model. I just saw how the queries are working and these are the queries constructed for c1, c2 and c3 respectively.

SELECT "testapp_parentmodel"."id", "testapp_parentmodel"."slug" FROM "testapp_parentmodel" INNER JOIN "testapp_parentmodel_links" ON ("testapp_parentmodel"."id" = "testapp_parentmodel_links"."to_parentmodel_id") WHERE "testapp_parentmodel_links"."from_parentmodel_id" = 4  LIMIT 21

SELECT "testapp_parentmodel"."id", "testapp_parentmodel"."slug" FROM "testapp_parentmodel" INNER JOIN "testapp_parentmodel_links" ON ("testapp_parentmodel"."id" = "testapp_parentmodel_links"."to_parentmodel_id") WHERE "testapp_parentmodel_links"."from_parentmodel_id" = 5  LIMIT 21

SELECT "testapp_parentmodel"."id", "testapp_parentmodel"."slug" FROM "testapp_parentmodel" INNER JOIN "testapp_parentmodel_links" ON ("testapp_parentmodel"."id" = "testapp_parentmodel_links"."to_parentmodel_id") WHERE "testapp_parentmodel_links"."from_parentmodel_id" = 6  LIMIT 21

From what I see the queries must be actually UNION of two queries which fetch data both from, "from" and "to" fields in the "testapp_parentmodel_links" table.It should look some thing like this, from what I have understood:

SELECT "testapp_parentmodel"."id", "testapp_parentmodel"."slug" FROM "testapp_parentmodel" INNER JOIN "testapp_parentmodel_links" ON ("testapp_parentmodel"."id" = "testapp_parentmodel_links"."to_parentmodel_id") WHERE "testapp_parentmodel_links"."from_parentmodel_id" = 4  LIMIT 21
UNION
SELECT "testapp_parentmodel"."id", "testapp_parentmodel"."slug" FROM "testapp_parentmodel" INNER JOIN "testapp_parentmodel_links" ON ("testapp_parentmodel"."id" = "testapp_parentmodel_links"."from_parentmodel_id") WHERE "testapp_parentmodel_links"."to_parentmodel_id" = 4  LIMIT 21

Is this an elegant approach? If so can some one help me implement this? I went through the code of QuerySet, Manager classes and other parts of django.db.models. How to go about from here? I am very keen on fixing this issue. Kindly help me.

--
Thanks and regards,
 Madhusudan.C.S

Blogs at: www.madhusudancs.info
Official Email ID: madhu...@madhusudancs.info

P.S: I am really sorry if the text is not wrapped. I am still not understanding how wrapping works here. Will correct it from next mail. Hope Auto text wrapping works.

Alex Gaynor

unread,
Mar 11, 2009, 11:41:02 AM3/11/09
to django-d...@googlegroups.com
This looks like it may just be a symptom of http://code.djangoproject.com/ticket/10237 if I'm reading htis correctly.

Alex

--
"I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire
"The people's good is the highest law."--Cicero

Madhusudan C.S

unread,
Mar 11, 2009, 3:45:28 PM3/11/09
to django-d...@googlegroups.com
Hi Alex,
    First of all thanks a lot for the reply.
The problem looks very similar. I applied the patch and tried out. But it doesn't seem to solve the problem at least for the data set I created as above. So problem exists some where else too. Any pointers to where it might be? (The query i.e being generated essentially remains the same even after applying the supplied patch). But manager.symmetrical which used to return False now correctly returns True.

Madhusudan C.S

unread,
Mar 11, 2009, 6:25:03 PM3/11/09
to django-d...@googlegroups.com
Hi Alex,
    Sorry for wasting your time :(
This looks like it may just be a symptom of http://code.djangoproject.com/ticket/10237 if I'm reading htis correctly.

The problem looks very similar. I applied the patch and tried out. But it doesn't seem to solve the problem at least for the data set I created as above. So problem exists some where else too. Any pointers to where it might be? (The query i.e being generated essentially remains the same even after applying the supplied patch). But manager.symmetrical which used to return False now correctly returns True.

Sorry for sending this mail without testing. Did not notice that to test the patch the new data must be saved into the database or the old data updated. Was just trying with the existing data after applying the patch. The patch submitted in the ticket #10237 works fine for me.
Thanks to justinlilly for the patch and thanks Alex for the help. Sorry for bothering you a lot.


Alex Gaynor

unread,
Mar 11, 2009, 6:37:10 PM3/11/09
to django-d...@googlegroups.com
This was anything but time wasted, we now know something we didn't before.
Reply all
Reply to author
Forward
0 new messages