Hi Anssi,
Shouldn't first() and last() raise an exception if no ordering is
specified? This keeps it consistent with latest() which requires the user
to explicitly specify what field it wants to use as ordering.
Also, like you mentioned, IMHO these APIs are too similar (first, earliest,
last and latest) in name, yet the usage is completely different, with
latest() expecting a field name, the other filter args. What I also don't
like is that the filter_args expected by last() and first() are:
1. Doesn't allow exclude arguments
2. We already have .filter() method which does the same thing (filters a
queryset with passed kwargs)
So if I may suggest, I think a better option would be to change the methods
first() and last() to behave more like latest(), but they should return
None when the query returns no result. Example usage:
User.objects.exclude(a=b).filter(c=d).first('id') # Returns None if there's
no match
user = User.objects.exclude(a=b).filter(c=d).last('id')
if user:
# do things...
If last() and first() are introduced, perhaps we can also deprecate
latest() in the future because they're very similar.
What do you guys think?
Best,
Selwin
On Sunday, January 20, 2013 1:51:27 PM UTC+7, Anssi Kääriäinen wrote:
>
> On 10 tammi, 09:27, Wim Feijen wrote:
> > Hi,
> >
> > Ticket 19326 has been marked as ready for check-in for some time. Can
> > some-one have a look at it?
> >
> > https://code.djangoproject.com/ticket/19326
> >
> > Thanks,
> >
> > Wim
>
> I did some more polish to the patch. There is now also .last() method,
> and if there is no ordering in the queryset, then it will be
> automatically ordered by the primary key.
>
> I didn't commit the patch yet, as I wonder if there will be confusion
> about .latest(by_field), .last(filter_args). earliest(by_field)
> and .first(filter_args)?
>
> Currently, the usage is this:
> a =
> Article.objects.order_by('headline').first(pub_date__year=2005)
> which will return first article by headline if any found or None if no
> match. .last() will just change the ordering by first
> calling .reverse() on the qs.
>
> The patch is 100% ready for commit as far as I am concerned (cursory
> check of the changes doesn't hurt, of course). So, if one of the BDFLs
> sees the API as fine just go and commit the patch.
>
> Patch available from
> https://github.com/akaariai/django/compare/ticket_19326.
>
> - Anssi
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/ovi4mYStQHYJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
