Hi,
(the below is reordered)
On Wednesday 26 March 2014 21:44:22 Anssi Kääriäinen wrote:
>
> Actually I think we could use .get(default=None). The way to do this is:
> 1. Deprecate direct use of .get(default=lookup_value), instead ask users
> to do .get(Q(default=lookup_value)).
> 2. After deprecation, add support for
> .get(default=default_if_no_match_value)
>
> This is somewhat confusing API - if you have a column named default, users
> *will* try to do .get(default=lookup_value), no matter how much we document
> this special case. OTOH I don't believe having field named default is that
> common.
>
-0 on confusing APIs. As was noted in this thread, we already have something
similar with "defaults" on get_or_create(), but the value for that argument is
not valid for most fields (and in particular, not valid for any field in core);
so when reading code, it is immediately clear what the intention was. Here, it
will be easy to err on reading as well as writing.
> Another similar idea is to add support for .get(__default=None). One can't
> have a field named __default, or at least it won't work in any sane way
> with the ORM.
>
I find this ugly (I think I said so, but maybe I just intended to).
> On Thursday, March 27, 2014 3:10:13 AM UTC+2, Russell Keith-Magee wrote:
> > In my ideal world, the get(default=None) approach would be what we would
> > do; but, as others have pointed out, default is a valid column name, so
> > this option isn't available to us.
Actually, I think there is a sane spelling for this we could use, but it's one
that shouldn't be introduced lightly.
The idea is to use the *args, not the **kwargs. Currently, the only thing that
can go in the positional args is Q objects; we could also allow "policy
objects" (naming improvements welcome). Thus,
MyModel.objects.get(Default(None), field=value)
MyModel.objects.get(Q(...), Default(my_default_instance))
or something similar. However, this is a whole new style of arguments to
queries, so I'd be very reluctant to add it just for this use case; and I
can't easily come up with many others. The only one I could think of was query
hints (in the SQL sense), and that's not very strong.
> > We already have a shortcut for
> > get_object_or_404; a matching get_object_or_none makes sense to me, and
> > puts the API where it make sense to me - as a shortcut for someone who is
> > repeating the "catch DoesNotExist" pattern regularly and wants an easier
> > way.
That makes a lot of sense to me too.
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/4867577.ngfmiHINPY%40deblack.
For more options, visit https://groups.google.com/d/optout.
