I believe someone had linked a ticket before, but I was unable to find one, so I went ahead and submitted it here: http://code.djangoproject.com/ticket/11938 ---- David Cramer
On Wed, Sep 23, 2009 at 6:41 PM, David Cramer <[email protected]> wrote: > As usual, my apologies for lacking context :) > > The problem happens when you try to query with a model containing a foreign > key that references a to_field. It fails to pass the proper attribute. > > # Exampe 1, a simple get lookup > class ExampleBrokenModel(models.Model): > user = models.ForeignKey(User, to_field="username") > > user = User.objects.get(username="a_username") > > # The following will fail due to the fact it's going to try to do user_id= > user.pk, rather > # than user_id=user.username > ExampleBrokenModel.objects.get(user=user) > > I will attach additional tests to a ticket, see also [1] > > I'm not aware of this ever working properly, but I'm not going to dig up > tickets. You can take my word for it as we've been dealing with it at this > project for a year, and had been working with Django almost 2 years before > that. Either way, it's not a big deal, the fact is it doesn't work as > advertised, and it is advertised. > > You would have to talk to the author of newforms-admin, which I believe was > Brian Rosner. There is some special code for handling to_field lookups in > the admin. > > [1] http://www.pastethat.com/LUYWh > > ---- > David Cramer > > > > > On Wed, Sep 23, 2009 at 6:27 PM, Karen Tracey <[email protected]> wrote: > >> On Wed, Sep 23, 2009 at 4:59 PM, David Cramer <[email protected]> wrote: >> >>> >>> I haven't brought this up for quite a while, but ``to_field`` still >>> does not function properly (at least as of 1.1, I haven't noticed any >>> changes addressing it though). The issue is that anywhere you do a GET >>> lookup, it doesn't process the to_field properly:: >>> >>> # TODO: waiting on to_field fix >>> try: >>> opt = cls.objects.get(business=business.business_id, >>> key=key) >>> except cls.DoesNotExist: >>> opt = cls.objects.create(business=business, key=key, >>> value=value) >>> >>> >> That's supposed to illustrate the problem with to_field? It's a snippet >> of code lacking any context with a cryptic TODO comment. What is the model >> definition here (which would at least give a clue where to_field applies)? >> How would this code be different if this "to_field fix" were applied? >> >> This query: >> >> >> http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=~to_field&order=priority<http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=%7Eto_field&order=priority> >> >> shows 4 open tickets with the "to_field" in their summary. Is the problem >> you are referring to one of these? >> >> >>> This seems to have been solved in the admin branch when newforms-admin >>> landed, but seems mostly ignored in the core field's. This issue has >>> also existed as far as I can remember, which is quite some time :) >>> >>> >> I've not been around as long as you so without reference to a ticket or >> something unfortunately I have no idea what problem you are talking about. >> I also don't know what you mean by it being fixed in admin but not in "core >> fields". Admin doesn't define fields, so huh? I can't really parse what >> you are trying to say here. >> >> >> >>> So, what do we need to get the ball rolling on this. I don't have much >>> time myself to commit, but if it's minor things such as writing some >>> tests that easily reproduce all errors we've found. We'll glady commit >>> those. Other than though my day is just filled, but I'd love to see >>> this get fixed. It's something that's advertised as a core feature, >>> has been for 3+years, and simply doesn't work. >>> >>> >> The tests you mention filed in a ticket, or attached to one of those >> tickets from above if indeed one of those is reporting the problem you are >> talking about, would be helpful. If none of those tickets reflect the >> problem you are talking about, then a complete description of the problem >> would be helpful; as it is I have no idea what problem you are referring >> to. >> >> >>> >> >> On a side note, something that I also believe is a bug, is that >>> ManyToManyRel.get_related_field() returns the primary key field no >>> matter what. I'm not sure if thats the intended functionality of that >>> or not, but to me it sounds like this should refer to the field in the >>> through model (even if that model is virtual) that it's pointing to. >>> >> >> A filed ticket describing the problem and how to recreate it would have a >> better chance of getting remembered and fixed than a side note in an email. >> >> Karen >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" 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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
