Slicing is cool, but I'm +1 for deprecating it and using .limit(). Slicing in my mind should return an iterable and you shouldn't be messing w/ properties on that iterable, even though somethings you might want to.
For example: We extend the queryset model for our fulltext search -- which uses slicing to do pages. But there's more information we could add, such as total results, max results, etc, to the queryset result model. You could do blah = mysearchquery[0:10], and then blah.someattr, but it just doesn't feel right. Whereas doing blah = mysearchquery.limit(0, 10), and blah.attr actually makes sense. On Dec 4, 8:28 am, Forest Bond <[EMAIL PROTECTED]> wrote: > Hi, > > Replying to self. > > On Tue, Dec 04, 2007 at 11:25:42AM -0500, Forest Bond wrote: > > objects = MyModel.objects.filter(site=1).fetch() > > first_one = objects[0] > > Incidentally, qs.fetch() need not be equivalent to list(qs). It could just > trigger qs to cache the results of the query and return qs itself. That would > ensure that the query is only executed once, unless further manipulations are > attempted. > > Not that that is necessarily the right thing to do. > > -Forest > -- > Forest Bondhttp://www.alittletooquiet.net > > signature.asc > 1KDownload --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
