Hi Selwin and Anssi,
Anssi, thanks for improving the patch and getting it ready for commit!
Selwin, you are right that .filter() and .first() are very similar.
Rationale for .first() is to get rid of the pattern
try:
instance = ModelX.objects.get
except ObjectDoesNotExist:
instance = None
, which is a very common pattern so an exception seems out of place. Using
filter to get the first result or none would still require three lines.
Other alternative patterns are in this thread.
For me, example use cases would be Address.objects.first() which would
return the first address in a list, when browsing through all addresses in
detail view, or page.music_files.first() where we just have one music file
per page or none. MusicFile.objects.first(page=page) should work too.
Indeed, .earliest('timestamp') could be expressed as
.order_by('timestamp').first() , and latest similarly. In my opinion these
are consistent with .filter() and .get().
Default ordering by id if no order is specified is the same behaviour as in
the admin, so I would argue not to raise an exception when no ordering is
specified, but to keep it like it is and order by id. Thanks for adding
that Anssi!
Looking forward to other input,
Best regards,
Wim
On Sunday, 20 January 2013 12:18:22 UTC+1, Selwin Ong wrote:
>
> 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 <wimfei...@gmail.com> 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/-/V8ZQdJ2cGlUJ.
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.
