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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c9833cf7-6113-4405-b5e6-8de2dda1fdb6n%40googlegroups.com.
