On Feb 9, 3:12 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> So after some back and forth about whether this should or shouldn't
> work, there didn't seem to be any resolution. Your gut feeling looks
> right to me Rob: it should probably work as you expect (no collision),
> although it won't surprise me if it doesn't (because ContentTypes are
> mixed into generic relations, which is part of core still).
>
> I'll have a look at this, since I've delved into models.loading a lot in
> the past (and intend to do so again in the near future).
After seeing the select_related(depth) patch go in, that made me want
to see if limiting the depth of this affected the error I was seeing
in the SQL. Result: it doesn't affect it. Using select_related()
still adds those strange tables that don't really exist.
But! I did find the root of what's causing this bug and it may occur
regardless of the name of the model...
Our content system has these relationships:
Content -> ContentType
Content -> Attribute -> ContentType
There's more than one way to follow the relationships to land at
ContentType. (Aside: We originally added ContentType to Attribute so
we could filter the pulldowns of our Attributes by ContentType since
our content attributes only make sense for certain types of content.)
If I remove the FK from Attribute -> ContentType, the extra junk in
the SQL goes away.
It should be easy to test this on table names other than ContentType.
Hopefully this is an extra clue to track this down, and maybe this bug
is already known?
Cheers!
Rob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
