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
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
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 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 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
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
On 10/11/06, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>
> Michael Radziej wrote:
> hmm.. maybe i am only implementing strange web-applications, but up to
> now, i never ever needed the caching behaviour of the QuerySets...so i
> probably will have to ALWAYS use the iterator() method.
>
>
> (just fo
Russell Keith-Magee wrote:
>
>> somehow i assumed that the QuerySets never load in the whole result-set,
>> except when they are forced (cast to list for example). but now i see
>> that of course, if you cache the results, then you will have all the
>> results in memory anyway...
>
> This is wha
On 10/11/06, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee wrote:
> sorry, but is this the description of the __iter__ case, or the
> iterator() case?
Now that you mention it (looks furiously at code...)
Ok - it doesn't work quite like I thought it did. Here's the rundown
Russell Keith-Magee wrote:
> On 10/11/06, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>> Russell Keith-Magee wrote:
>
>> sorry, but is this the description of the __iter__ case, or the
>> iterator() case?
>
> Now that you mention it (looks furiously at code...)
>
> Ok - it doesn't work quite li
Does this caching of QuerySets live beyond one request ? I assume each
thread gets its own cache, right ?
For us poor users of shared hosting, where we're using multiple
processes that are killed and respawned many times, this isn't very
helpful...
Unless I haven't understood all this, in that c
orestis schrieb:
> Does this caching of QuerySets live beyond one request ? I assume each
> thread gets its own cache, right ?
>
> For us poor users of shared hosting, where we're using multiple
> processes that are killed and respawned many times, this isn't very
> helpful...
>
> Unless I haven
Yep :) Thanks!
--~--~-~--~~~---~--~~
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
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 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/11/06, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>
> (i'm not sure i understand what you mean by "iterator protocol")
The "iterator protocol" basically refers to __iter__() and next(). Its
the stuff that python calls behind the scenes when you iterate over
something.
http://docs.python.org/l
16 matches
Mail list logo
