Re: Support for `Q` objects in `get_or_create` and `update_or_create`

['Mike Lissner' via Django developers (Contributions to Django itself)]

OK, I created a ticket, but I fear I'm not the best person to get the docs
ironed out. I took a stab at it, but it was terrible and I got the sense
it'd get rejected for not explaining things properly/well. Perhaps somebody
else can pick this up:

https://code.djangoproject.com/ticket/29148

Mike

On Tue, Feb 20, 2018 at 6:39 PM Adam Johnson  wrote:

> I think it's perfectly sane to document the filter + get_or_create combo,
> feel free to open a ticket and pull request
>
> On 20 February 2018 at 20:26, 'Mike Lissner' via Django developers
> (Contributions to Django itself) 
> wrote:
>
>> This is my first message here, and sure enough I'm necromancing this
>> thread from 2016!
>>
>> Below there's a message about how to use Q objects with get_or_create by
>> chaining them. This works! But it's not documented. Is it crazy to document
>> this?
>>
>> I think I used the advice in this thread a while back to write some code,
>> but when I came upon the code today, it baffled me. I went to the docs, but
>> there was no mention of this technique there, and so, here I am again at
>> this thread.
>>
>> Thanks,
>>
>> Mike
>>
>> On Tuesday, August 16, 2016 at 12:27:30 PM UTC-7, Flavio Curella wrote:
>>>
>>> It didn't occur to me that it could be done that way. Thanks!
>>>
>>> I'm closing the ticket as 'invalid'
>>>
>>>
>>> On Tuesday, August 16, 2016 at 2:03:02 PM UTC-5, charettes wrote:

 Hi Flavio,

 Is there a reason we can't document chaining filter() with these
 methods when
 querying with Q() objects?

 Person.objects.filter(
 Q(first_name='George') | Q(first_name='Bruce')
 ).get_or_create(defaults={'last_name': 'Harrison'})

 If `defaults` was stil only passable as a kwarg this could have worked
 but at
 this point I don't think it's worth the additionnal complexity as
 there's no way
 to introduce a fully backward compatible API without deprecating passing
 `defaults` as the first arg.

 Even if we were to agree on a new unlikely used kwarg name to specify
 the query
 object the `(get|update)_or_create` APIs would end up disgressing from
 the `filter()`
 and `get()` ones which is the main objective of this proposed change I
 beleive.

 Simon

 Le mardi 16 août 2016 13:57:25 UTC-4, Flavio Curella a écrit :
>
> I'm thinking about adding support for `Q` to `get_or_create` and
> `update_or_create`. I've summarized my thoughts at
> https://code.djangoproject.com/ticket/27070.
>
>
> I have a couple of unsolved question; the most critical is the one Tim
> raises: if we were to add another keyword argument to those methods, how
> much of an impact will it have? Can we find a name that we can be
> reasonably confident is not used as a model field by anybody (or a _very_
> small number of users)?
>
>
> Thanks,
> –Flavio.
>
 --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>
>
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/6c1285c8-94da-49bc-bbbf-c76b8e6cfb3e%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/e3sJ6OiHEd0/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2SjuQX3E828znmVaBMFjjP7whBk24qtwpAD29scsuDcA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Mike Lissner
Executive Director
Free Law Project
@freelawproject
https://free.law/donate/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To 

Re: Support for `Q` objects in `get_or_create` and `update_or_create`

[Adam Johnson]

I think it's perfectly sane to document the filter + get_or_create combo,
feel free to open a ticket and pull request

On 20 February 2018 at 20:26, 'Mike Lissner' via Django developers
(Contributions to Django itself)  wrote:

> This is my first message here, and sure enough I'm necromancing this
> thread from 2016!
>
> Below there's a message about how to use Q objects with get_or_create by
> chaining them. This works! But it's not documented. Is it crazy to document
> this?
>
> I think I used the advice in this thread a while back to write some code,
> but when I came upon the code today, it baffled me. I went to the docs, but
> there was no mention of this technique there, and so, here I am again at
> this thread.
>
> Thanks,
>
> Mike
>
> On Tuesday, August 16, 2016 at 12:27:30 PM UTC-7, Flavio Curella wrote:
>>
>> It didn't occur to me that it could be done that way. Thanks!
>>
>> I'm closing the ticket as 'invalid'
>>
>>
>> On Tuesday, August 16, 2016 at 2:03:02 PM UTC-5, charettes wrote:
>>>
>>> Hi Flavio,
>>>
>>> Is there a reason we can't document chaining filter() with these methods
>>> when
>>> querying with Q() objects?
>>>
>>> Person.objects.filter(
>>> Q(first_name='George') | Q(first_name='Bruce')
>>> ).get_or_create(defaults={'last_name': 'Harrison'})
>>>
>>> If `defaults` was stil only passable as a kwarg this could have worked
>>> but at
>>> this point I don't think it's worth the additionnal complexity as
>>> there's no way
>>> to introduce a fully backward compatible API without deprecating passing
>>> `defaults` as the first arg.
>>>
>>> Even if we were to agree on a new unlikely used kwarg name to specify
>>> the query
>>> object the `(get|update)_or_create` APIs would end up disgressing from
>>> the `filter()`
>>> and `get()` ones which is the main objective of this proposed change I
>>> beleive.
>>>
>>> Simon
>>>
>>> Le mardi 16 août 2016 13:57:25 UTC-4, Flavio Curella a écrit :

 I'm thinking about adding support for `Q` to `get_or_create` and
 `update_or_create`. I've summarized my thoughts at
 https://code.djangoproject.com/ticket/27070.


 I have a couple of unsolved question; the most critical is the one Tim
 raises: if we were to add another keyword argument to those methods, how
 much of an impact will it have? Can we find a name that we can be
 reasonably confident is not used as a model field by anybody (or a _very_
 small number of users)?


 Thanks,
 –Flavio.

>>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/6c1285c8-94da-49bc-bbbf-
> c76b8e6cfb3e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2SjuQX3E828znmVaBMFjjP7whBk24qtwpAD29scsuDcA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for `Q` objects in `get_or_create` and `update_or_create`

['Mike Lissner' via Django developers (Contributions to Django itself)]

This is my first message here, and sure enough I'm necromancing this thread 
from 2016!

Below there's a message about how to use Q objects with get_or_create by 
chaining them. This works! But it's not documented. Is it crazy to document 
this?

I think I used the advice in this thread a while back to write some code, 
but when I came upon the code today, it baffled me. I went to the docs, but 
there was no mention of this technique there, and so, here I am again at 
this thread. 

Thanks,

Mike

On Tuesday, August 16, 2016 at 12:27:30 PM UTC-7, Flavio Curella wrote:
>
> It didn't occur to me that it could be done that way. Thanks!
>
> I'm closing the ticket as 'invalid'
>
>
> On Tuesday, August 16, 2016 at 2:03:02 PM UTC-5, charettes wrote:
>>
>> Hi Flavio,
>>
>> Is there a reason we can't document chaining filter() with these methods 
>> when
>> querying with Q() objects?
>>
>> Person.objects.filter(
>> Q(first_name='George') | Q(first_name='Bruce')
>> ).get_or_create(defaults={'last_name': 'Harrison'})
>>
>> If `defaults` was stil only passable as a kwarg this could have worked 
>> but at
>> this point I don't think it's worth the additionnal complexity as there's 
>> no way
>> to introduce a fully backward compatible API without deprecating passing
>> `defaults` as the first arg.
>>
>> Even if we were to agree on a new unlikely used kwarg name to specify the 
>> query
>> object the `(get|update)_or_create` APIs would end up disgressing from 
>> the `filter()`
>> and `get()` ones which is the main objective of this proposed change I 
>> beleive.
>>
>> Simon
>>
>> Le mardi 16 août 2016 13:57:25 UTC-4, Flavio Curella a écrit :
>>>
>>> I'm thinking about adding support for `Q` to `get_or_create` and 
>>> `update_or_create`. I've summarized my thoughts at 
>>> https://code.djangoproject.com/ticket/27070. 
>>>
>>>
>>> I have a couple of unsolved question; the most critical is the one Tim 
>>> raises: if we were to add another keyword argument to those methods, how 
>>> much of an impact will it have? Can we find a name that we can be 
>>> reasonably confident is not used as a model field by anybody (or a _very_ 
>>> small number of users)?
>>>
>>>
>>> Thanks,
>>> –Flavio.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6c1285c8-94da-49bc-bbbf-c76b8e6cfb3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for `Q` objects in `get_or_create` and `update_or_create`

[Flavio Curella]

It didn't occur to me that it could be done that way. Thanks!

I'm closing the ticket as 'invalid'


On Tuesday, August 16, 2016 at 2:03:02 PM UTC-5, charettes wrote:
>
> Hi Flavio,
>
> Is there a reason we can't document chaining filter() with these methods 
> when
> querying with Q() objects?
>
> Person.objects.filter(
> Q(first_name='George') | Q(first_name='Bruce')
> ).get_or_create(defaults={'last_name': 'Harrison'})
>
> If `defaults` was stil only passable as a kwarg this could have worked but 
> at
> this point I don't think it's worth the additionnal complexity as there's 
> no way
> to introduce a fully backward compatible API without deprecating passing
> `defaults` as the first arg.
>
> Even if we were to agree on a new unlikely used kwarg name to specify the 
> query
> object the `(get|update)_or_create` APIs would end up disgressing from the 
> `filter()`
> and `get()` ones which is the main objective of this proposed change I 
> beleive.
>
> Simon
>
> Le mardi 16 août 2016 13:57:25 UTC-4, Flavio Curella a écrit :
>>
>> I'm thinking about adding support for `Q` to `get_or_create` and 
>> `update_or_create`. I've summarized my thoughts at 
>> https://code.djangoproject.com/ticket/27070. 
>>
>>
>> I have a couple of unsolved question; the most critical is the one Tim 
>> raises: if we were to add another keyword argument to those methods, how 
>> much of an impact will it have? Can we find a name that we can be 
>> reasonably confident is not used as a model field by anybody (or a _very_ 
>> small number of users)?
>>
>>
>> Thanks,
>> –Flavio.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/164e44aa-6133-470a-a178-438d8d772497%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for `Q` objects in `get_or_create` and `update_or_create`

[charettes]

Hi Flavio,

Is there a reason we can't document chaining filter() with these methods 
when
querying with Q() objects?

Person.objects.filter(
Q(first_name='George') | Q(first_name='Bruce')
).get_or_create(defaults={'last_name': 'Harrison'})

If `defaults` was stil only passable as a kwarg this could have worked but 
at
this point I don't think it's worth the additionnal complexity as there's 
no way
to introduce a fully backward compatible API without deprecating passing
`defaults` as the first arg.

Even if we were to agree on a new unlikely used kwarg name to specify the 
query
object the `(get|update)_or_create` APIs would end up disgressing from the 
`filter()`
and `get()` ones which is the main objective of this proposed change I 
beleive.

Simon

Le mardi 16 août 2016 13:57:25 UTC-4, Flavio Curella a écrit :
>
> I'm thinking about adding support for `Q` to `get_or_create` and 
> `update_or_create`. I've summarized my thoughts at 
> https://code.djangoproject.com/ticket/27070. 
>
>
> I have a couple of unsolved question; the most critical is the one Tim 
> raises: if we were to add another keyword argument to those methods, how 
> much of an impact will it have? Can we find a name that we can be 
> reasonably confident is not used as a model field by anybody (or a _very_ 
> small number of users)?
>
>
> Thanks,
> –Flavio.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/86589b5a-a2ad-4074-87e5-2f098491206f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Support for `Q` objects in `get_or_create` and `update_or_create`

[Flavio Curella]

I'm thinking about adding support for `Q` to `get_or_create` and 
`update_or_create`. I've summarized my thoughts at 
https://code.djangoproject.com/ticket/27070. 


I have a couple of unsolved question; the most critical is the one Tim 
raises: if we were to add another keyword argument to those methods, how 
much of an impact will it have? Can we find a name that we can be 
reasonably confident is not used as a model field by anybody (or a _very_ 
small number of users)?


Thanks,
–Flavio.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b4c68e65-ea18-4c90-97ed-b9be099fff8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.