On Apr 7, 8:59 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > > I'd need to go spelunking through the code to be sure, but if this is > happening, I'd be guessing it's oversight. From a quick scan of the > test suite, I can't find an obvious test for values() on one-to-one > fields. > > As for the reason for this; OneToOne keys are a degenerate case of > foreign key, but in the reverse direction, they have a single value > (as opposed to the multiple values of a reverse foreign key). As a > result, the oversight would be failing to include reverse one-to-ones > in the list of valid names, overriding the default interpretation for > the ForeignKey from which they are inherited. > > So - it sounds like this should be reported as a ticket; If you could > also reduce this to a test case that is integrated into Django's test > suite (regressiontests/one_to_one_regress would be a good place, > because it has o2o models ready to use), that would be very helpful. > > Yours, > Russ Magee %-)
Hi Russ, Thanks for taking a look at this. I knocked up a quick test case and was surprised to find that it passed under Django 1.3 (I hadn't tried testing under 1.3 before, but I'd checked the two sections of code in 1.3 that relate to the problem being triggered and they hadn't changed so I was fairly sure it hadn't been directly fixed!). After much rummaging around I eventually found that #5768 http://code.djangoproject.com/ticket/5768 has removed the restriction on M2M being used in .values and .values_list (i.e. the call to self.query.add_fields changed to say m2m were allowed) so the fact that setup_joins is treating a reverse OneToOne the same as a reverse ForeignKey (i.e. it's potentially many to many in nature) doesn't lead to the exception being raised any more. So alas if I log the bug and supply a test then the test will pass :). It may not matter that the oversight I outlined exists if it can't manifest as a problem now - although I suspect it's useful to have a regression test on values() and values_list() referencing the reverse of O2O in case of future changes. A test that does a deeper call to queryset.query.add_fields() with allow_m2m set to False could be written, but I guess that's a no-no as it's testing the implementation rather than the public API. Want me to log it as a bug and include the test that'll pass and some notes explaining what's gone on? (I can, and have, run the same test against Django 1.2.5 to prove the test fails where the problem hasn't been masked by the change to the call to add_fields). Regards, Matt -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
