I am completely agree with Jörg. Simply Mixin with own get_or_none help solve you, @Dave Gaeddert your asks.
Here we have Other big issue, which always omitted between Django developers in GET method: Multiple objects exception without Already received objects. Get made "len", len created one or many objects. We already loose time for that (init time * N objects). Probably I can catch Exception and decide in Exception, what I want to do with that objects. BUT! I cannot do it. Get throws error without received objects. If I want to get those objects, I should send again request to database. I should wait, again. Can we add queryset with cached_objects in MultipleObjectsReturned Exeption? Yes. Definitely. Have we this yet? No Mit freundlichen Grüßen, DI Mag. Maxim Danilov +43(681)207 447 76 ma...@wpsoft.at -----Original Message----- From: django-developers@googlegroups.com [mailto:django-developers@googlegroups.com] On Behalf Of Jörg Breitbart Sent: Friday, June 24, 2022 11:56 AM To: django-developers@googlegroups.com Subject: Re: Idea: Add .checked(<True>/<False>) to QuerySet as alternative to .filter() w/ .first() @Dave Gaeddert Since you mentioned it - what should a get_or_none method do about multiple objects? Still raise? Silently "cast" to None (imho semantically wrong)? Return the underlying queryset (or any other "multiple objects container thingy")? The problem with .get() is - it may end in 3 different states (tristate - None, one object, multiple objects), where only one state is the expected case. To me handling the other unexpected ones as exceptions seems to be a very common pattern in python (thus also newbies should be able to handle it properly in their code). Now a .get_or_none() would shift the "good results" to (None, one object) still leaving multiple objects out. Did we gain here anything? Not if multiple objects is still within reach (eg. uniqueness cannot be assumed from the filter conditions) - ppl would still have to write exception handling code. Just forgetting that is like a time bomb that might go off anytime a project aggregates more production data (welcome to error 500 websites / dying servers). But if .get_or_none() would handle multiple objects without raising (eg. returning the queryset) - we haven't gained anything either, we just surfaced the fact, that .get is only a convenient function on top of filtered search queries. And ppl still have to deal with the tristate result in their code. Maybe I am overlooking something - currently I dont see, how any of that might be helpful in terms of easier API usage. Am 23.06.22 um 16:57 schrieb Dave Gaeddert: > I'll lob in my 2 cents that I actually think `get_or_none` would be > great to have, in the same way that I imagine people think > `get_or_create` is useful. You can try/catch yourself in both cases > (example is basically the exact same > https://docs.djangoproject.com/en/4.0/ref/models/querysets/#get-or-create), > but especially for people new to Django, having a method for it is a lot > easier to grasp. The MultipleObjectsReturned exception is more of a > modeling/uniqueness error in my experience (not sure I've ever written a > catch for this...), but doing .get and knowing it may not exist is super > common — much easier to have a method for that than force everyone to > think through all the ramifications of using .get vs .filter (and/or > .first) etc. > > I'd also guess that people don't want to create a Manager if they don't > have to (which I'd also consider an advanced topic). > > https://stackoverflow.com/questions/3090302/how-do-i-get-the-object-if-it-exists-or-none-if-it-does-not-exist-in-django > > Dave > > On Wednesday, June 22, 2022 at 5:27:52 AM UTC-5 j.bre...@netzkolchose.de > wrote: > > I somewhat second what Adrian wrote: > > - try-except handling seems to be the most idiomatic way to me > - a flag altering API behavior as .get(..., raises=False) might come > handy, and to avoid naming collisions in arguments this could also be > shaped as a separate get_or_none() method - but: I somewhat doubt its > usefulness just cluttering the API further for low benefit, also > nothing > stops you from wrapping the exception way into such a query helper > (or a > more advanced resemblance of .get as Uri does). In fact the exception > will create a tiny runtime overhead on interpreter side, but thats > really tiny compared to the db roundtrip (thus against the whole .get + > helper runtime). > > Imho a chaining .checked() method on the manager/queryset is not a good > idea, as it might create more API ambiguity - What should .checked() > do, > if it is not followed by .get()? > > Cheers, jerch > > > > -- > 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 > <mailto:django-developers+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/c9833cf7-6113-4405-b5e6-8de2dda1fdb6n%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/c9833cf7-6113-4405-b5e6-8de2dda1fdb6n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- netzkolchose.de UG (haftungsbeschränkt) Geschäftsführer: Jörg Breitbart Handelsregister: HRB 504791 Amtsgericht Jena Steuer-Nr.: 161/115/07450 USt-IdNr.: DE268234065 -- 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/18eb5df7-85fd-8e8a-3632-351d90da50d3%40netzkolchose.de. -- 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/000001d887b4%24b7ad2370%2427076a50%24%40wpsoft.at.
