[Django] #24613: Documentation Note for defer might need an example.
Django
--------------------------------------+--------------------
Reporter: Naddiseo | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.8
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+--------------------
The paragraph in the note section of the `defer` documentation is not
immediately obvious to what it's implying. My understanding is that it's
suggesting that one can use two django models to load data from a single
database table, is that the only implication, or is there another?
I think adding an example would help to clarify what exactly is meant by
the paragraph.
This is what I think it means:
{{{#!python
class MyCommonlyUsedModel(models.Model):
class Meta:
managed = False
db_table = 'app_largetable'
f1 = models.Field(...)
f2 = models.Field(...)
class MyUsuallyDeferredFieldsModel(models.Model):
class Meta:
managed = False
db_table = 'app_largetable'
deferred_f3 = models.Field(...)
deferred_f4 = models.Field(...)
# A model that allows the migrations framework to also manage the table
# Not sure if this actually works, but would allow for a more DRY approach
class MyManagedModel(MyCommonlyUsedModel, MyUsuallyDeferredFieldsModel):
class Meta:
managed = True
tb_table = 'app_largetable'
}}}
If the above example is acceptable as an example - and is actually what
the note is about - I don't mind creating a PR.
--
Ticket URL: <https://code.djangoproject.com/ticket/24613>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Naddiseo | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: => 0
* stage: Unreviewed => Accepted
* needs_tests: => 0
* needs_docs: => 0
Comment:
Yes, an example wouldn't hurt. There wasn't much additional context in the
commit where that text was added 70e59aeaf85161ed26044c000a43af46719265ad.
Did you test your example? I am not sure field inheritance will work
properly with suggested approach, but maybe so. To make the example
simpler, there probably isn't a need for `MyUsuallyDeferredFieldsModel`
(just put those fields on `MyManagedModel`).
--
Ticket URL: <https://code.djangoproject.com/ticket/24613#comment:1>
Django
Reporter: Naddiseo | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by akulakov):
In this paragraph:
> only use defer() when you cannot, at queryset load time, determine if
you will need the extra fields or not.
Shouldn't it be, instead, ".. when you cannot, before the queryset load
time, determine if you will need the extra fields or not." ?
--
Ticket URL: <https://code.djangoproject.com/ticket/24613#comment:2>
Django
Reporter: Naddiseo | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
Maybe, actually I am not quite sure what the intention of the wording is
there.
--
Ticket URL: <https://code.djangoproject.com/ticket/24613#comment:3>
Django
Reporter: Naddiseo | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by akulakov):
* cc: andrei.avk@… (added)
Comment:
I haven't used defer() myself before, but from reading the section, the
idea seems to be that: if you can determine what fields need to be left
out before queryset load time, use some other solution; if you can NOT do
that, that's the only case where you'd use defer() because that's your
only option.
--
Ticket URL: <https://code.djangoproject.com/ticket/24613#comment:4>
Django
Reporter: Naddiseo | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
What does "queryset load time" mean? When the queryset is evaluated and
the database query occurs, or something else?
--
Ticket URL: <https://code.djangoproject.com/ticket/24613#comment:5>
Django
Reporter: Naddiseo | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.8
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Naddiseo):
* has_patch: 0 => 1
Comment:
Created a pull request with a minimal example.
https://github.com/django/django/pull/4539
--
Ticket URL: <https://code.djangoproject.com/ticket/24613#comment:6>
Django
Reporter: Naddiseo | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.8
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by akulakov):
Replying to [comment:5 timgraham]:
> What does "queryset load time" mean? When the queryset is evaluated and
the database query occurs, or something else?
I think it means when .only() or .defer() method is executed, there's two
time points of interest: module load time, when you can define a module
with a subset of fields, and queryset object creation time (or
modification of existing queryset), when you provide the list of fields to
defer. These are the only two times when you could provide this list of
fields, so if you know the list at the module load time, it's preferred to
define it as a model with a subset of fields, but if you don't know at
module load time, then you don't have this option and you only have
defer() and only() left to use.
--
Ticket URL: <https://code.djangoproject.com/ticket/24613#comment:7>
Django
Reporter: Naddiseo | Owner: nobody
Type: Cleanup/optimization | Status: closed
Component: Documentation | Version: 1.8
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"dd99f57710bb4930561a6c049f54719af80850ec" dd99f577]:
{{{
#!CommitTicketReference repository=""
revision="dd99f57710bb4930561a6c049f54719af80850ec"
Fixed #24613 -- Added example to QuerySet.defer() documentation
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24613#comment:8>
Django
Reporter: Naddiseo | Owner: nobody
Type: Cleanup/optimization | Status: closed
Component: Documentation | Version: 1.8
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"bcd7f396f9c821897e2a9dab565711135ca7f9c8" bcd7f39]:
{{{
#!CommitTicketReference repository=""
revision="bcd7f396f9c821897e2a9dab565711135ca7f9c8"
[1.7.x] Fixed #24613 -- Added example to QuerySet.defer() documentation
Backport of dd99f57710bb4930561a6c049f54719af80850ec from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24613#comment:9>
Django
Reporter: Naddiseo | Owner: nobody
Type: Cleanup/optimization | Status: closed
Component: Documentation | Version: 1.8
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"fe533fc537e8eecd9ad592b140387f44d21727ab" fe533fc5]:
{{{
#!CommitTicketReference repository=""
revision="fe533fc537e8eecd9ad592b140387f44d21727ab"
[1.8.x] Fixed #24613 -- Added example to QuerySet.defer() documentation
Backport of dd99f57710bb4930561a6c049f54719af80850ec from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24613#comment:10>