Re: Add an defer=True option for model fields

2019-02-20 Thread Adam Johnson
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

Re: Add an defer=True option for model fields

2019-02-20 Thread Josh Smeaton
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,

Re: Add an defer=True option for model fields

2019-02-19 Thread Dan Davis
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

Add an defer=True option for model fields

2019-02-19 Thread Dan Davis
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

Re: #26481 - Add a "strict mode" for defer()/only()

2016-05-01 Thread Fabien Schwob
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

Re: #26481 - Add a "strict mode" for defer()/only()

2016-04-26 Thread Tim Graham
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

#26481 - Add a "strict mode" for defer()/only()

2016-04-22 Thread 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

Request for eyes familiar with ORM internals and defer/only (attn: Malcolm)

2011-10-20 Thread Tai Lee
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

Re: Querysets with "only()" and "defer()" slower than without?

2010-08-08 Thread OverKrik
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

Re: Querysets with "only()" and "defer()" slower than without?

2010-08-06 Thread Anssi Kaariainen
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

Re: Querysets with "only()" and "defer()" slower than without?

2010-08-06 Thread OverKrik
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

Re: Querysets with "only()" and "defer()" slower than without?

2010-08-05 Thread Jacob Kaplan-Moss
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

Re: Querysets with "only()" and "defer()" slower than without?

2010-08-05 Thread OverKrik
, 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

Re: Querysets with "only()" and "defer()" slower than without?

2010-08-05 Thread Jeremy Dunck
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. -

Re: Querysets with "only()" and "defer()" slower than without?

2010-08-05 Thread OverKrik
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

Re: Querysets with "only()" and "defer()" slower than without?

2010-08-05 Thread Alex Gaynor
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

Re: Querysets with "only()" and "defer()" slower than without?

2010-08-05 Thread OverKrik
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

Re: Querysets with "only()" and "defer()" slower than without?

2010-08-05 Thread OverKrik
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

Re: Querysets with "only()" and "defer()" slower than without?

2010-08-05 Thread Dennis Kaarsemaker
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

Re: Querysets with "only()" and "defer()" slower than without?

2010-08-05 Thread Jacob Kaplan-Moss
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

Querysets with "only()" and "defer()" slower than without?

2010-08-05 Thread OverKrik
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

Re: defer() and only()

2009-03-21 Thread Malcolm Tredinnick
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] >

defer() and only()

2009-03-21 Thread Ivan Sagalaev
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(

Re: defer().

2008-11-23 Thread David Cramer
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

Re: defer().

2008-11-22 Thread Jacob Kaplan-Moss
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

Re: defer().

2008-11-22 Thread David Cramer
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. > > >

Re: defer().

2008-11-21 Thread Malcolm Tredinnick
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. >

Re: defer().

2008-11-21 Thread Jacob Kaplan-Moss
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

Re: defer().

2008-11-21 Thread David Cramer
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

Re: defer().

2008-11-21 Thread [EMAIL PROTECTED]
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

Re: defer().

2008-11-21 Thread Ian Kelly
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

defer().

2008-11-21 Thread David Cramer
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())"