On 9/26/07, David Cramer <[EMAIL PROTECTED]> wrote:
> The only way this can be done as of current is by saying
> "MYmodel(id=1)" which is a hack. This technically shouldn't be done as
> you're instantiating an object without a dataset. What happens when
> the shared memory select related patch
The only way this can be done as of current is by saying
"MYmodel(id=1)" which is a hack. This technically shouldn't be done as
you're instantiating an object without a dataset. What happens when
the shared memory select related patch were to go in? You'd now have
an instance of a model thats
Seems Collin, I and co will have to agree to disagree on this. It's
all relative I guess, you think we're upside down, I think you're
upside down :-) Just a shame to burn thousands of man hours on
something which is so plainly inconsistent to fresh eyes.
Collin Grady wrote:
> James Bennett
James Bennett said the following:
> 1. It breaks consistency with how we currently do things
I still disagree with you there. It would only break consistency if it
was actually crossing the relation and checking the ID field of the
other table.
Since it is *not* a cross-relation lookup, not
On Mon, Sep 24, James Bennett wrote:
> As I see it, the existence of the "somefieldname_id" property is an
> implementation detail of ForeignKey -- the data comes back as part of
> the row we select, and we need to stick it somewhere.
Ehm ... does this mean that this might change, or is this
On 9/24/07, Simon Litchfield <[EMAIL PROTECTED]> wrote:
> That's it, right there in a nutshell. Empty your head of Django for a
> second, have another look; do you not see the inconsistency there?
No :)
As I see it, the existence of the "somefieldname_id" property is an
implementation detail of
Gary Wilson wrote:
> This is a tricky way around django.db.models.base.Model.__init__'s current
> enforcement of the foreign key field (without the _id) wanting an instance,
> but shouldn't be needed if we implement the above (meaning create() would act
> like get() in that you could pass either
James Bennett said the following:
> >>> 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's it, right there in a
Gary Wilson said the following:
> I say you are looking at it backwards here. It's not that get() and
> get_or_create() don't work with fkeyname_id, it's that Model() and create()
> don't work with fkeyname.
I disagree strongly with that. It's already established that
obj.fkeyname is the
Collin Grady wrote:
> David Cramer said the following:
>> 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
>> instance.
Yes, you are correct.
> But .create() already works with fkeyname_id, it's just
Jacob Kaplan-Moss said the following:
> That is, make::
>
> Foo.objects.get_or_create(bar__id=1)
>
> Work the same way as::
>
> Foo.objects.get_or_create(bar__id=1, defaults={"bar_id": 1})
That would probably be better than the current, but I'm still on David's
side in thinking that
James Bennett said the following:
> 1. The lookup syntax *always* uses double underscores for relations.
But checking fkey_id isn't trying to cross the relation - it wants the
local value :)
> 2. The lookup syntax *only* lets you look up by things that actually are
> fields.
*cough*
On 9/19/07, Collin Grady <[EMAIL PROTECTED]> wrote:
> But .create() already works with fkeyname_id, it's just get() and
> get_or_create() that don't :)
So seems to me the best way to solve this is to make get_or_create()
understand how to swizzle a lookup of the form "fk__id" or "fk__pk"
into a
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
> instance.
OK, so let's do this exhaustively.
>>> my_id = 3
>>>
David Cramer said the following:
> 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
> instance.
But .create() already works with fkeyname_id, it's just get() and
get_or_create() that don't :)
--
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
instance.
On Sep 19, 11:30 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On 9/19/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
> > Yes, my biggest
Tom Tobin said the following:
> *Way* -1. I don't want to be looking at code and wondering whether a
> particular query is dealing with a local field named "foo_bar" or a
> related model "foo" with a field "bar".
Except when you do user__id it /is/ referring to the local column, it
just
On 9/19/07, David Cramer <[EMAIL PROTECTED]> wrote:
> Yes, my biggest argument is I want to use .get_or_create() and I don't
> have an instance of the row (the id) I'm trying to insert. I'm *not*
> going to query for this instance (I'll write SQL before I add extra
> queries just to do an
Yes, my biggest argument is I want to use .get_or_create() and I don't
have an instance of the row (the id) I'm trying to insert. I'm *not*
going to query for this instance (I'll write SQL before I add extra
queries just to do an update/insert), and I don't like creating a fake
temporary object,
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
On Wed, Sep 19, James Bennett wrote:
>
> David Cramer has asked that Django's ORM lookup syntax be changed to
> allow a single underscore for a foreign key lookup; in other words,
> the following two examples would become equivalent:
>
> UserProfile.objects.get(user__id=3) #Currently works
>
On 9/19/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> David Cramer has asked that Django's ORM lookup syntax be changed to
> allow a single underscore for a foreign key lookup; in other words,
> the following two examples would become equivalent:
>
> UserProfile.objects.get(user__id=3)
On 9/19/07, James Bennett <[EMAIL PROTECTED]> wrote:
> David Cramer has asked that Django's ORM lookup syntax be changed to
> allow a single underscore for a foreign key lookup; in other words,
> the following two examples would become equivalent:
>
> UserProfile.objects.get(user__id=3)
23 matches
Mail list logo
