On 29 huhti, 00:09, ptone wrote:
> A couple just quick observations.
>
> defer and only are tasks/concepts used when doing a query based on
> knowledge of your dataset - adding them to the model itself expands the
> number of places where this concept is considered. This has some good and
> some b
Hi again,
On Friday 26 April 2013, Anssi Kääriäinen wrote:
> [...]
> In almost every case it is better to try to minimize the amount of
> queries than the amount of loaded fields. The cases where you have
> deferred multiple fields, need only one of them later on, and there is
> a field that you c
On Thursday, April 25, 2013 2:37:10 PM UTC-7, Anssi Kääriäinen wrote:
>
> On 25 huhti, 23:44, Alex Ogier wrote:
> > On Thu, Apr 25, 2013 at 2:10 PM, Florian Apolloner <
> f.apollo...@gmail.com>wrote:
> >
> > > On Thursday, April 25, 2013 7:06:06 PM UTC+2, Adrian Holovaty wrote:
> >
> > >> A
On 26 huhti, 00:59, I wrote:
> Now, if there would be some way to avoid the dynamic model subclassing
> used by deferred loading then storing the set of deferred fields per
> instance would be more than welcome. One possibility might be defining
> Model.__getattr__. If you end up in __getattr__ and
On Friday 26 April 2013, Alex Gaynor wrote:
> Sorry, I misunderstood the original request. Yes, you're right Anssi and
> Adrian, finding them on demand is reasonable.
>
Reasonable, but not entirely necessary for this.
I have code that requires something like that; when it is time to "undefer"
th
Sorry, I misunderstood the original request. Yes, you're right Anssi and
Adrian, finding them on demand is reasonable.
Alex
On Thu, Apr 25, 2013 at 4:59 PM, Anssi Kääriäinen
wrote:
> On 25 huhti, 20:08, Alex Gaynor wrote:
> > This sounds like a reasonable request, I don't yet have an opinion o
On 25 huhti, 20:08, Alex Gaynor wrote:
> This sounds like a reasonable request, I don't yet have an opinion on API
> or anything. One tiny thing I'd like to note though, "change DeferredAttribute
> to find all *other* DeferredAttributes". I don't think `finding` is the
> right way to think about i
On 25 huhti, 23:44, Alex Ogier wrote:
> On Thu, Apr 25, 2013 at 2:10 PM, Florian Apolloner
> wrote:
>
> > On Thursday, April 25, 2013 7:06:06 PM UTC+2, Adrian Holovaty wrote:
>
> >> Also, I should mention that this should be *optional* behavior, as the
> >> current behavior is reasonable for the
On Thu, Apr 25, 2013 at 2:10 PM, Florian Apolloner wrote:
> On Thursday, April 25, 2013 7:06:06 PM UTC+2, Adrian Holovaty wrote:
>>
>> Also, I should mention that this should be *optional* behavior, as the
>> current behavior is reasonable for the common case. The API for specifying
>> this "load
On Thursday, April 25, 2013 7:06:06 PM UTC+2, Adrian Holovaty wrote:
>
> Also, I should mention that this should be *optional* behavior, as the
> current behavior is reasonable for the common case. The API for specifying
> this "load everything" behavior is a separate discussion. Perhaps a keywor
This sounds like a reasonable request, I don't yet have an opinion on API
or anything. One tiny thing I'd like to note though, "change DeferredAttribute
to find all *other* DeferredAttributes". I don't think `finding` is the
right way to think about it, a `DeferredAttribute` with loadall semantics
At the moment, if you call defer() or only() on a QuerySet, then access the
deferred fields individually, *each* access of a deferred field will result
in a separate query.
For example, assuming a User model with username/bio/location fields, this
is what currently happens:
"""
>>> u = User.objec
12 matches
Mail list logo
