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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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.
