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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

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 <a href="https://code.djangoproject.com/ticket/27070" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F27070\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNESfFXeu7qUKysBZDSDIUl6HmRk6w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F27070\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNESfFXeu7qUKysBZDSDIUl6HmRk6w&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

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 <a href="https://code.djangoproject.com/ticket/27070" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F27070\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNESfFXeu7qUKysBZDSDIUl6HmRk6w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F27070\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNESfFXeu7qUKysBZDSDIUl6HmRk6w&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

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

Mike Lissner
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 <a href="https://code.djangoproject.com/ticket/27070" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F27070\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNESfFXeu7qUKysBZDSDIUl6HmRk6w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F27070\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNESfFXeu7qUKysBZDSDIUl6HmRk6w&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

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

Adam Johnson-2
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) <[hidden email]> 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 [hidden email].
To post to this group, send email to [hidden email].
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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

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

Mike Lissner
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:


Mike

On Tue, Feb 20, 2018 at 6:39 PM Adam Johnson <[hidden email]> 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) <[hidden email]> 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 [hidden email].



--
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 [hidden email].
To post to this group, send email to [hidden email].
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 unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/CAKs1xOHAtVLOQMOiCfYny25dryuX-FJU0wTG2yqCbNgYpY2oNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.