On 9/19/07, David Cramer <[EMAIL PROTECTED]> wrote:
> I don't believe .create() allows you to say myforeignkey=1, correct me
> if I'm wrong, but I think it throws an error about it needing to be a
> <ForeigNkeyClass> instance.
OK, so let's do this exhaustively.
>>> my_id = 3
>>> UserProfile.objects.create(user_id=my_id) #works
>>> UserProfile.objects.get(user__id=my_id) # works
>>> UserProfile.objects.get_or_create(user__id=my_id, defaults={
'user_id': my_id }) #works
That covers get(), create() and get_or_create(). In none of these
cases did you need to have an instance of the related model available
in memory.
So: since your argument about "needing an instance" is unfounded,
what's to gain by breaking the consistency of the lookup syntax?
One more time to recap:
1. The lookup syntax *always* uses double underscores for relations.
2. The lookup syntax *only* lets you look up by things that actually are fields.
Your proposal would violate both of these points of consistency, by
breaking (1) to allow a single underscore and breaking (2) to allow
lookup by something that, rather than being a field, is an
implementation detail of the field.
What's the gain?
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
