I think the use case is probably quite niche, and I'd like to know some more concrete details than the current comment on the ticket "(E.g. only update if the value of a DateTimeField is less than some value)". It may be there's a way to achieve the same application-level outcome using a different design. If it is necessary, there are also some analogous use cases, like passing a 'create' condition predicate or passing conditions to get_or_create, that it seems it would make sense to implement at the same time but would complicate Django and the scope of the change further.
Also I agree with Simon that passing around predicate callables doesn't feel very Django-ey or pythonic. On Fri, 28 Dec 2018 at 16:31, charettes <charett...@gmail.com> wrote: > Thanks for taking the time to post here Joshua! > > The main reason why I asked to gather feedback from this list is that I'm > not convinced > that the benefits outweighs the additional complexity this will add to the > already quite > loaded update_or_create() signature handling and how the fact a callable > predicate > is not something that is used anywhere else in Django AFAIK. > > The fact this can be achieved with the same number of queries by doing a > save(update_fields) from the return value of a previous get_or_create with > a > bit of boilerplate pushes me to a -1 because I don't think it's a > common enough > pattern to warrant the addition of a specialized option. > > Cheers, > Simon > >  https://code.djangoproject.com/ticket/30053#comment:13 > > Le vendredi 28 décembre 2018 11:15:33 UTC-5, Joshua Cannon a écrit : >> >> Howdy folks! >> >> At the suggestion of Simon Charette, I'd like to get feedback on how the >> community feels about the feature request #30053 >> <https://code.djangoproject.com/ticket/30053>. >> The gist of the problem is that sometimes the "update" part of >> "update_or_create" should be conditional. The proposed solution adds a >> backwards-compatible "update_condition" parameter to "update_or_create" >> which should be a unary callable that takes in the retrieved table instance >> and returns a boolean of whether the update should be performed. >> >> Nasir Hussain has already started work on a possible solution on PR 10800 >> <https://github.com/django/django/pull/10800>. >> >> I'd love to hear other people's thoughts. >> > -- > 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 firstname.lastname@example.org. > 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/82df287a-9e59-496b-956e-b0d4bd79760d%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/82df287a-9e59-496b-956e-b0d4bd79760d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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 email@example.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/CAMyDDM1k7d1cHdDVROhB5GYrXdreJk%3DcSMYdeJbogB_C%3Dp5EYQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.