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 Op donderdag 29 november 2012 23:45:38 UTC+1 schreef Wim Feijen het volgende: > > Hi Anssi, > > When I thought about it, the most prominent usecase seemed to me of > getting one of a set of many and expecting just one result. In that case, > get_or_none would suffice. However, as a method name, I prefer first() for > being concise. > > For me it is ok to just have the first() method without last(). For > example, sqlalchemy defines first() but not last(). Although jquery does > define both. > > I agree that ordering should be applied and in case no ordering is > specified on the model, I really would like to use ordering by pk. Doesn't > filter provide results by default in that order? Unfortunately, I was not > able to comprehend the workings of clone so I am not sure. > > Regards, Wim > > Op donderdag 29 november 2012 08:12:28 UTC+1 schreef Anssi Kääriäinen het > volgende: >> >> On 29 marras, 01:13, Wim Feijen <wimfei...@gmail.com> wrote: >> > Hi, the patch has been updated and now works. >> > >> > Still, feedback would be appreciated. So, Anssi, Jacob? >> >> Apart of some whitespace errors the patch looks good to me. >> >> There isn't last() method in the patch. Implementing one is going to >> be a little more challenging as one needs to change the direction of >> all the ordering clauses. Do we want one in the same patch? >> >> A bigger problem might be that we already have .latest() which does >> something a bit different. I wonder if having both .last(filter_args) >> and .latest(by_field) is going to be confusing. >> >> Another API issue is that should .first() check for some ordering? >> This could add some protection. In testing conditions things might >> work, but when updates are done to the rows the expected ordering >> suddenly changes. One option is to do automatic ordering on PK if >> there isn't any other ordering present. >> >> I still like the idea of .get_default() mainly for the added "if >> multiple objects returned, then throw an error" protection it gives. >> From implementation/maintenance perspective these are really easy >> additions, from API bloat perspective maybe not... >> >> - 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/-/KNzxgP8L-V0J. 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.
