Thanks everyone for your comments. I solved the problem, not very elegantly, but solved nevertheless:
q1 = OurProduct.objects.select_related().exclude(productoverride__customer=1) q2 = ProductOverride.objects.select_related().filter(customer=1) from itertools import chain customerpricelist = list(chain(q1, q2)) I now have different fieldnames in the DICT generated by Q1 and Q2 (for example: ourproduct.code and code - for what should be values in the same field!). This caused a bit of a nasty looking TEMPLATE to resolve to screen correctly but the result works great, implementation a severe workaround! Thanks again. On Oct 8, 10:45 pm, Sebastian Goll <[email protected]> wrote: > On Sat, 8 Oct 2011 16:30:37 -0500 > Javier Guerra Giraldez <[email protected]> wrote: > > > > > > > > > > > On Sat, Oct 8, 2011 at 8:18 AM, Michal Petrucha <[email protected]> > > wrote: > > > Behind the scenes, Django does a JOIN. Its type (INNER od LEFT OUTER) > > > is decided based on whether the left-hand column (your ForeignKey > > > field) is allowed to be NULL or not. > > > the weird part, is that is takes the same choice on reverse > > relationships, which isn't necessarily appropriate. > > > for example, model A has a foreign key to B. when reading A records > > with select_related, it makes sense that if the FK is NULLable, it > > uses a LEFT OUTER join while if it's not NULLable, use an INNER join. > > when I have a B object, it's _really_ handy to have the reverse > > relationship set up for me; but what if i want to select those B > > objects that doesn't have any A? > > > this works... > > > B.objects.filter(a_set__isnull=True) > > > but only if the FK from A to B has the null=True argument. > > > and if I want to make the FK from A to B non-NULLable? maybe an A > > record doesn't make any sense without B, but B without any A does. so > > i don't put (null=True); so in the query above, i get an INNER join > > followed by the condition that a.id IS NULL, and the result set is > > empty. :-( > > > the only solution i've found is to make the FK NULLable, even when it > > doesn't make sense. I'd love to see a separate reverse_null=True > > argument (by default reverse_null==null) on the FK, that would make > > the reverse join a LEFT OUTER one while still prohibiting an A record > > without B. > > > am i missing something? > > This is part of the erroneous behavior fixed by a proposed patch to #16715 > [1]. In this ticket, several other model relations lead to the wrong join > type. Not having reverse relations be null-able is one of the observations. > > Maybe you, or some other developer, can review the proposed patch for this > problem? The part of this mail, making reverse relations null-able is the > more trivial part of the patch, and essentially a one-liner in > django/db/models/sql/compiler.py. "new_nullable = f.null or None" in line 674 > – as of r16928 – should be "new_nullable = True" since reverse relations > should always be considered null-able. See the proposed patch (#16715) for > details. > > Sebastian. > > [1]https://code.djangoproject.com/ticket/16715 -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
