Michael Radziej wrote:
> Malcolm Tredinnick schrieb:
>> Interestingly, looking at QuerySet.iterator() and QuerySet.__iter__,
>> they aren't synonyms. The point is that QuerySet.__iter__ iterates over
>> the result of QuerySet._get_data(), which actually sucks everything into
>> memory before itera
for example:class Venta(models.model): cost = models.FloatField(...) if you has over 100 rows, and you have to sum the all costs with an for iteration will be very slow,but if you have a method .sum('cost')
for example:Venta.objects.all().sum('cost')PS: sorry for my bad english :
Hi all,
in django.contrib.admin.ChangeList.get_filters
there is a line:
if self.lookup_opts.admin.list_filter and not
self.opts.one_to_one_field:
does anybody know why there is the second part of the condition?
when I commented the second part out, the filters worked fine.
I spent some t
Malcolm Tredinnick schrieb:
> Interestingly, looking at QuerySet.iterator() and QuerySet.__iter__,
> they aren't synonyms. The point is that QuerySet.__iter__ iterates over
> the result of QuerySet._get_data(), which actually sucks everything into
> memory before iterating. On the other hand, Quer
On 10/10/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> There was a big argument about this, and IIRC Adrian settled it by
> deciding on the .all(). This is one of the main threads regarding the
> issue:
>
> http://groups.google.com/group/django-developers/browse_frm/thread/f64127c9b63e2ae5/e1
On 10/10/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> So now I'm just confused as to what might be "best". Certainly two sides
> to this. I probably prefer the current consistency a little more, but
> then there's iterator(). So I'm going to do the professional thing here:
> hope that Adr
On Tue, 2006-10-10 at 05:30 -0700, Andrew Durdin wrote:
> Malcolm Tredinnick wrote:
> >
> > The consistent design idea at work here is that a manager provides those
> > methods that return a Queryset object. That is why we have .all() in the
> > first place: it provides a way to convert from a man
Malcolm Tredinnick wrote:
>
> The consistent design idea at work here is that a manager provides those
> methods that return a Queryset object. That is why we have .all() in the
> first place: it provides a way to convert from a manager object to a
> Queryset without applying any filters or restri
On Tue, 2006-10-10 at 04:06 -0700, Andrew Durdin wrote:
> Looking at models.Manager, I noticed that for convenience it implements
> many of the public methods of QuerySet, delegating the calls to its
> query set. This obviously allows for more convenient behaviour, such
> as writing MyModel.obje
Looking at models.Manager, I noticed that for convenience it implements
many of the public methods of QuerySet, delegating the calls to its
query set. This obviously allows for more convenient behaviour, such
as writing MyModel.objects.filter(whatever) instead of
MyModel.objects.all().filter(wh
10 matches
Mail list logo
