et for this one already, filed 4 years ago by me :)
>
> https://code.djangoproject.com/ticket/24096
>
> There are a few options described, but I think `defer=True` was winning
> out. I don't think we considered an `undefer`, but a `defer(None)` would
> fix that. Once that API is
There is a ticket for this one already, filed 4 years ago by me :)
https://code.djangoproject.com/ticket/24096
There are a few options described, but I think `defer=True` was winning
out. I don't think we considered an `undefer`, but a `defer(None)` would
fix that. Once that API is built,
bjects.all()]
>
> Or, if he cannot do that, to simply defer the field:
>
> [obj for obj in
> LicensesDBView.objects.defer('scanned_license').all()]
>
> I was not sure whether to tell him to implement a ModelManager with a
> get_queryset() metho
take the BinaryField out of the
database-level view, to protect the ORM from reading these large files into
memory, as in:
[obj for obj in LicensesDBView.objects.all()]
Or, if he cannot do that, to simply defer the field:
[obj for obj in
I understand, but it's maybe hard to be aware of this solution. Maybe it's
just something that can be raised in the documentation ?
2016-04-27 2:26 GMT+02:00 Tim Graham :
> I guess there's some question about whether or not we need to make changes
> in Django given Anssi's comment, "Overriding Mo
I guess there's some question about whether or not we need to make changes
in Django given Anssi's comment, "Overriding Model.refresh_from_db() allows
raising failure when deferred field is accessed - is this enough for you
use case?"
On Friday, April 22, 2016 at 7:07:07 AM UTC-4, Fabien SCHWOB
Hello,
I would like to try to work on the #26481 ticket, and I'm new to the inner
workings of Django, but I thinks it's the best way to learn more about it.
Several enhancements / modifications are related to this ticket :
* The first one is adding a strict argument to only() that will raise an
I've run into a bug that is exposed when using defer() or only() with
select_related(). A couple others have come across it, and there is an
existing ticket.
Exceptions appear to be silenced somewhere under normal circumstances
when evaluating `queryset` objects, which made it difficult to
Kaariainen wrote:
> On Aug 6, 12:09 am, Jacob Kaplan-Moss wrote:
>
> > If you're benchmarking this against a small dataset and an in-memory
> > database like SQLite I'd fully expect to see the defer/only benchmark
> > to be slower. That's because every time a
On Aug 6, 12:09 am, Jacob Kaplan-Moss wrote:
> If you're benchmarking this against a small dataset and an in-memory
> database like SQLite I'd fully expect to see the defer/only benchmark
> to be slower. That's because every time a QS is chained it needs to be
> co
n about 2 weeks.
>
> I'm looking forward to seeing it. I agree that the results are
> counter-intuitive; seems there's *something* going on here that
> shouldn't be happening. I'd expect, given your scenario, that the
> only/defer versions would be faster, so the fact
hat
shouldn't be happening. I'd expect, given your scenario, that the
only/defer versions would be faster, so the fact that they're not
means that the situation's more complicated than my mental model.
I'm going to be trying to reproduce your results locally, both using a
clone o
, restarting db every time and performing 10 000 request
> > to warm db before measuring execution time.
> > Just in case, I've tried running tests in only-full-only-full and
> > defer-full-defer-full patters and got same results.
>
> This sounds like a pretty good test. C
in only-full-only-full and
> defer-full-defer-full patters and got same results.
This sounds like a pretty good test. Can you attach the code? I'm
sure it's not pretty, but I've been meaning to work on benchmarks for
a long time and it'd be a shame to not reuse your effort.
-
t confused, does this mean that only() and defer() should
not be used in single-item pk queries?
On Aug 6, 1:34 am, Alex Gaynor wrote:
> On Thu, Aug 5, 2010 at 5:32 PM, OverKrik wrote:
> > I am performing every test 10 times, excluding one fastest and one
> > slowest result, res
in only-full-only-full and
> defer-full-defer-full patters and got same results.
>
> On Aug 6, 1:18 am, Dennis Kaarsemaker wrote:
>> On do, 2010-08-05 at 16:09 -0500, Jacob Kaplan-Moss wrote:
>>
>> > - What database engine are you using?
>> > - Where's
I am performing every test 10 times, excluding one fastest and one
slowest result, restarting db every time and performing 10 000 request
to warm db before measuring execution time.
Just in case, I've tried running tests in only-full-only-full and
defer-full-defer-full patters and got same re
Hi Jacob, thx for reply and sorry for not enough additional info in
original post. I was thinking that this issue can be related only to
python part of the bench, as everything looked ok with queries. Just
in case I've tested query generated by only\defer queryset using raw
SQL bench and com
On do, 2010-08-05 at 16:09 -0500, Jacob Kaplan-Moss wrote:
> - What database engine are you using?
> - Where's the database being stored (same server? other server?
> in-memory?)
> - How much data is in the database?
> - How big is that "info" field on an average model?
- Were OS/database level
u using?
- Where's the database being stored (same server? other server? in-memory?)
- How much data is in the database?
- How big is that "info" field on an average model?
If you're benchmarking this against a small dataset and an in-memory
database like SQLite I'd fully expe
Hi, I am testing performance of three querysets
1.
for pk in xrange(1,5):
user = User.objects.only("power_level").get(pk = pk)
d = user.power_level
2.
for pk in xrange(1,5):
user = User.objects.defer("name","email","age","info").get(pk
= pk)
d = user
On Sat, 2009-03-21 at 13:09 +0300, Ivan Sagalaev wrote:
> Hello everyone!
>
> Just played with new defer() and only() and noticed that fields deferred
> with only() aren't loaded when asked explicitly. I.e.:
>
> a = Article.objects.defer('text')[0]
>
Hello everyone!
Just played with new defer() and only() and noticed that fields deferred
with only() aren't loaded when asked explicitly. I.e.:
a = Article.objects.defer('text')[0]
a.text # <-- does a new query as expected
a = Article.objects.only(
roposed for fields as include-
> > only.
>
> From the ticket description:
>
> > We should also provide the inverse of hide() -- perhaps called expose()? --
> > which would
> > take a list of field names to *include* rather than *exclude*. This would
> > be an opt
uld also provide the inverse of hide() -- perhaps called expose()? --
> which would
> take a list of field names to *include* rather than *exclude*. This would be
> an opt-in
> instead of an opt-out.
Additionally, ``fields(*fieldnames)`` and ``defer(*fieldnames)`` have
been mentioned at
12:53 -0800, David Cramer wrote:
> > I agree. The internals are shared among both, that's why I'd much
> > rather see a good API around inclusion/exlusion.
>
> And reading the ticket would have revealed that it discusses both
> defer() and an opposite.
>
> >
On Fri, 2008-11-21 at 12:53 -0800, David Cramer wrote:
> I agree. The internals are shared among both, that's why I'd much
> rather see a good API around inclusion/exlusion.
And reading the ticket would have revealed that it discusses both
defer() and an opposite.
>
On Fri, Nov 21, 2008 at 2:05 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> I know personally myself, and several others who expressed
> opinions, wanted more than just an exclude option, but an include-only
> option.
That's part of this proposal, as the previous discussions indicated.
No need to
elly" <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Nov 21, 2008 at 1:05 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> > > I won't use defer, and I won't recommend people use it. I think it's
> > > not good practice. It's like using .sele
ot in excluded_fields].
On Nov 21, 3:23 pm, "Ian Kelly" <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 21, 2008 at 1:05 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> > I won't use defer, and I won't recommend people use it. I think it's
> > not good pr
On Fri, Nov 21, 2008 at 1:05 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> I won't use defer, and I won't recommend people use it. I think it's
> not good practice. It's like using .select_related() implicitly. You
> really need to explicitly pass th
To avoid messing with the 1.1 Roadmap anymore. What happened with defer
(). I know personally myself, and several others who expressed
opinions, wanted more than just an exclude option, but an include-only
option.
Is this part of the "Exclude fields in a SELECT (QuerySet.defer())"
32 matches
Mail list logo