Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()
On Thu, Jul 14, 2022 at 4:09 PM Dave Gaeddert wrote: > Yeah, I hope I'm not coming off as being too pushy, but I'm just curious > why that is. Mariusz or Adam, did what I said about it being *more* than > just an alias for `filter().first()` make sense or am I missing something? > (Different behavior for multiple results — on accident or otherwise) > Speaking for myself: I’d be against it because we’re getting into combinatorial territory with diminishing returns. Adding this one opens the door to equally long and repetitive threads in the future asking for all the others, and with less room to push back each time. Currently, Django covers the common cases of “if you didn’t find a match, 404” and “if there’s not exactly one result for this, throw an exception and let me catch it”. The fact that you can make other variants kinda work if you use first() or similar methods doesn’t, to me, obligate Django to also provide the full matrix of methods doing all the someone-might-want-it combinations of DoesNotExist, MultipleObjectsReturned, and None. People who want specific behaviors not covered by the built-in stuff should write their own, or somebody should make a django-all-the-get-single-object-methods package and everybody who wants one of these methods can install and use it. > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg_UjHey%3DnTq8y0zycbCAQe9Cx%3DMh%2BaVFDu1hjukmae3pg%40mail.gmail.com.
Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()
> I'm not the first to suggest adding an additional shortcut, e.g. django.shortcuts.get_object_or_none which would work similarly to get_object_or_404 Personally I'm not a fan of it being in "shortcuts". It makes sense to me that the 404 ones are there because they are only useful in a request/response lifecycle. Seems like a good call to keep that out of the standard queryset methods. But `get_or_none` could be used anywhere, and ergonomically (?) it makes more sense to me that people (especially people new to Django) would naturally find and use it if it were right next to `get` and `get_or_create` (in docs, autocomplete, search in your codebase, etc.). > I believe the main objection is against adding additional API to querysets. Yeah, I hope I'm not coming off as being too pushy, but I'm just curious why that is. Mariusz or Adam, did what I said about it being *more* than just an alias for `filter().first()` make sense or am I missing something? (Different behavior for multiple results — on accident or otherwise) Dave On Monday, July 11, 2022 at 1:06:04 AM UTC-5 m...@feinheit.ch wrote: > Hi > > I believe the main objection is against adding additional API to > querysets. get_object_or_404 only converts DoesNotExist into a 404 > exception and doesn't handle MultipleObjectsReturned. > > I'm not the first to suggest adding an additional shortcut, e.g. > django.shortcuts.get_object_or_none which would work similarly to > get_object_or_404 (and get_list_or_404 for that matter). The existing > shortcuts use functionality from several parts of Django (the ORM and the > request/response handling) which get_object_or_none wouldn't do, but its > behavior would be so close to what get_object_or_404 is doing that it may > be alright. > > OTOH even the implementation of this shortcut is so simple that I just add > it to each project when I have a need for it (I had a hard time finding it > because it comes up much less often than I thought it did). So I am not > proposing this addition personally but I wouldn't be against it either (if > that counts for anything). > > Best regards, > Matthias > > > > def get_object_or_none(klass, *args, **kwargs): > queryset = _get_queryset(klass) > if not hasattr(queryset, "get"): > klass__name = ( > klass.__name__ if isinstance(klass, type) else > klass.__class__.__name__ > ) > raise ValueError( > "First argument to get_object_or_404() must be a Model, > Manager, " > "or QuerySet, not '%s'." % klass__name > ) > try: > return queryset.get(*args, **kwargs) > except queryset.model.DoesNotExist: > return None > > > > On Sun, Jul 10, 2022 at 10:13 PM Dave Gaeddert > wrote: > >> Fair enough. To me, the `get_or_none` behavior with multiple results >> would still be to raise an exception (so it is just like `get` in that >> sense). And that’s the reason I personally don’t just see it as a shortcut >> for `filter().first()` — I have (as I’m sure others have) made the mistake >> before of *thinking* that I was using a unique query when that wasn’t >> necessarily true, so the multiple results exception has caught mistakes at >> runtime. I’d rather have that exception than use `filter().first()` and >> potentially show the wrong object to the wrong user, for example, and not >> figure out that I have a uniqueness/db problem. I like the fact that `get` >> raises those exceptions, I just think that try/except DoesNotExist/None is >> such a common behavior that a shortcut for *that* would actually be >> useful. >> >> Dave >> On Sunday, July 10, 2022 at 3:24:32 AM UTC-5 Adam Johnson wrote: >> >>> I'm also against adding get_or_none(), for the same reasons. Adding a >>> method to shortcut something that can already be done doesn't seem worth it >>> to me. >>> >>> On Sat, Jul 9, 2022 at 1:56 PM Mariusz Felisiak >>> wrote: >>> I'm against it because it's already easily achievable and it's debatable how it should behave with many results. IMO any new method would be confusing and in the case of unique filtering `get_or_none(unique_filters)` would be an alias for `.filter(unique_filters).first()`. To me, this is duplication of an API. There are several -0 in the previous thread (Shai, Florian) and you can count -1 from me. Best, Mariusz -- 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-develop...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aeb9be96-ec03-48f9-ae97-2859b62a1df6n%40googlegroups.com
Fellow Reports - July 2022
Week ending July 10, 2022 Released Django 4.0.6 and 3.2.14. *Triaged: * https://code.djangoproject.com/ticket/33820 - Querying "null" on key transforms for JSONField returns wrong results on SQLite. (accepted) https://code.djangoproject.com/ticket/33821 - Use _fk as suffix for augmented related model value fields (wontfix) https://code.djangoproject.com/ticket/33822 - New FormSet.edit_only only set when formset created by modelformset_factory (accepted) https://code.djangoproject.com/ticket/33824 - Django create don't return created object when triggers are fired (duplicate) https://code.djangoproject.com/ticket/33823 - inspectdb should generate related_name on same relation links. (accepted) https://code.djangoproject.com/ticket/33826 - delete_many()/set_many() crashes with empty values on Redis client. (accepted) https://code.djangoproject.com/ticket/33827 - Use of old MySQL version generate unknown default_storage_engine. (invalid) https://code.djangoproject.com/ticket/33828 - Admin's autocomplete_fields don't autofocus when opened (duplicate) https://code.djangoproject.com/ticket/33829 - BaseConstraint.deconstruct() and __eq__ operators don't take violation_error_message into account (created) https://code.djangoproject.com/ticket/33831 - How can I create model without primary_key (invalid) https://code.djangoproject.com/ticket/33833 - Close button styling issues in admin forms’ submit row (accepted) https://code.djangoproject.com/ticket/33832 - Support M2M validation using signals (invalid) https://code.djangoproject.com/ticket/33834 - Compact way to in-place update of the ORM model instance (duplicate) *Reviewed/committed: * https://github.com/django/django/pull/15814 - Fixed #33816 -- Fixed QuerySet.only() after select_related() crash on proxy models. https://github.com/django/django/pull/15818 - Fixed #33822 -- Fixed save() crash on model formsets when not created by modelformset_factory(). https://github.com/django/django/pull/15820 - Refs CVE-2022-34265 -- Properly escaped Extract() and Trunc() parameters. https://github.com/django/django/pull/15819 - Fixed #33823 -- Made inspectdb generate unique related_name when reverse accessor clashes. https://github.com/django/django/pull/15824 - Fixed #33826 -- Fixed RedisCache.set_many()/delete_many() crash with an empty list. https://github.com/django/django/pull/15812 - Refs #27236 -- Added generic mechanism to handle the deprecation of migration operations. https://github.com/django/django/pull/15828 - Fixed #33829 -- Made BaseConstraint.deconstruct() and equality handle violation_error_message. *Reviewed: * https://github.com/django/django/pull/15830 - Fixed #33781 -- Restored alignment for admin split-field timezone warnings. *Authored: * https://github.com/django/django/pull/15821 - Fixed RelatedGeoModelTest.test08_defer_only() on MySQL 8+ with MyISAM storage engine. https://github.com/django/django/pull/15820 - Refs CVE-2022-34265 -- Properly escaped Extract() and Trunc() parameters. https://github.com/django/django/pull/15829 - Fixed #33718 -- Dropped support for MySQL 5.7. https://github.com/django/django/pull/15832 - Refs CVE-2022-34265 -- Unified DatabaseOperations._convert_*_to_tz() hook names. Best, Mariusz -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/78ecf694-b092-0907-a873-f7c18985bde1%40gmail.com.
