Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

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

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

> To begin with - thats the place I dont like .get() at all. The fact that
> it might end up with multiple objects is a nuisance, but we cannot do
> much about it for API compat reasons
> ...

For what it's worth, I agree with what you're saying here too. Having a 
`unique_or_none` (and maybe `unique`) with that field checking could be 
cool, but in the interest of actually getting a change into Django, I 
assume `get_or_none` without that behavior is a much easier place to start.

On Sunday, June 26, 2022 at 2:07:34 PM UTC-5 j.bre...@netzkolchose.de wrote:

> Well from my own habits to use .get() only for unique filtering (>80% on 
> pks only) I also see some benefit of a .get_or_none() variant - it would 
> stop writing those exception handler wrappers over and over halfway 
> during project realization. A ready-to-go official way would reduce that 
> to a conditional expression from line one on.
>
> > .get_or_none() probably should allow to query only pks and
> > unique_together fields, so there will be no third state?
>
> To begin with - thats the place I dont like .get() at all. The fact that 
> it might end up with multiple objects is a nuisance, but we cannot do 
> much about it for API compat reasons. Idea - if we want such a changed 
> behavior - maybe call it "unique_or_none()" to make the difference 
> clear? If its called .get_or_none() imho it is better to stick to .get() 
> behavior regarding multiple objects (still raising).
>

-- 
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/b630d7a0-d832-41d0-985b-a7ae7ac1f1b6n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

I'm new to this... anybody know how the best way to push this forward? Or 
who can make a decision on whether something could/should be added to 
Django? I see some other tickets/discussions about basically the same thing:
https://code.djangoproject.com/ticket/17546

A lot has changed in 10+ years... seems like this could be reconsidered.

On Tuesday, June 28, 2022 at 9:27:52 AM UTC-5 Dave Gaeddert wrote:

> > To begin with - thats the place I dont like .get() at all. The fact that
> > it might end up with multiple objects is a nuisance, but we cannot do
> > much about it for API compat reasons
> > ...
>
> For what it's worth, I agree with what you're saying here too. Having a 
> `unique_or_none` (and maybe `unique`) with that field checking could be 
> cool, but in the interest of actually getting a change into Django, I 
> assume `get_or_none` without that behavior is a much easier place to start.
>
> On Sunday, June 26, 2022 at 2:07:34 PM UTC-5 j.bre...@netzkolchose.de 
> wrote:
>
>> Well from my own habits to use .get() only for unique filtering (>80% on 
>> pks only) I also see some benefit of a .get_or_none() variant - it would 
>> stop writing those exception handler wrappers over and over halfway 
>> during project realization. A ready-to-go official way would reduce that 
>> to a conditional expression from line one on.
>>
>> > .get_or_none() probably should allow to query only pks and
>> > unique_together fields, so there will be no third state?
>>
>> To begin with - thats the place I dont like .get() at all. The fact that 
>> it might end up with multiple objects is a nuisance, but we cannot do 
>> much about it for API compat reasons. Idea - if we want such a changed 
>> behavior - maybe call it "unique_or_none()" to make the difference 
>> clear? If its called .get_or_none() imho it is better to stick to .get() 
>> behavior regarding multiple objects (still raising).
>>
>

-- 
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/e21c2c22-5ba2-4421-8724-fa3f7e8f0b19n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

Hey Mariusz, thanks for the link — I found some other threads but not that 
one. Would you mind saying why you're personally against it (`get_or_none` 
specifically)?

At least how I read that thread, there was more debate about how to add it 
than whether to add it at all, and then Cal sort of "gave up" by suggesting 
a docs patch that I'm not sure ever happened anyway. I don't want to kick 
off a huge thing about it, but that one was 8 years ago and, like you said, 
it has come up a number of times over the years (maybe that's normal). 

Thanks!
Dave
On Wednesday, July 6, 2022 at 11:35:36 PM UTC-5 Mariusz Felisiak wrote:

> Hi,
>
> Adding `get_or_none()` was discussed several times and was always 
> rejected. This thread 
>  
> has a nice summary. Personally, I'm still against it.
>
> 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/46daf75f-bb6b-457a-8889-47b148b20d61n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

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

-- 
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/dbee041d-4f80-4e61-bf0a-1d6f4e2e22e6n%40googlegroups.com.

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

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

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

[Dave Gaeddert]

I'll drop it. Someone else can chime in if they want. Just to be clear, the 
work you all do on Django is much appreciated :) 

Thanks,
Dave
On Thursday, July 14, 2022 at 6:53:41 PM UTC-5 James Bennett wrote:

> 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/6c9d2559-6904-42c8-a1bf-a49904a9e4dan%40googlegroups.com.