@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.
