The following are assumptions I would make if both "worked". > UserProfile.objects.get(user__id=3) #Currently works
This is obviously a foreign key and clearly refers to the id field of the User model. Nuf' said. > UserProfile.objects.get(user_id=3) #Currently does not work There is no indication here as to whether this refers to a foreign key or not. Change the model to something other than User (which has a know convention) and I would assume this is referring to a user_id field of the UserProfile model. True, the foreign key is most likely stored in a user_id column in the db, but a quick glance at the above query provides no indication of that. It could just be a poorly named column with no relation to User. If it does, in fact, point to a foreign key, my assumption would be that a lighter/faster SQL statement would be generated avoiding the need to access the User table. More likely, the same SQL would be generated for either, so this is just misleading. So among the two above examples, leaving things alone is less confusing, as Marty Alchin points out. However, the ticket also seems to indicate that this works: UserProfile.objects.create(user_id=3) Which is not so consistent. I get the impression that this is the motivation for dcramer's argument. If is works for create, why not for get? Perhaps it shouldn't work for create either, although we probably don't want to go there for backwards compatibility issues. Just my $0.02 -- ---- Waylan Limberg [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
