Opened 10 years ago

Closed 3 years ago

#23816 closed New feature (wontfix)

Ability to defer model field by default

Reported by: Robert Coup Owned by: Denis.Tarykin
Component: Database layer (models, ORM) Version: dev
Severity: Normal Keywords:
Cc: akiskesoglou@…, Carlos Palol Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

Today's small #IWantAPony is to be able to mark model fields as deferred by default. No need to chase down every queryset and add .defer(), or use a custom manager setup & remember to set use_for_related_fields.

class MyModel(models.Model):
   enormous_field = models.TextField(defer=True)
   other_field = models.IntegerField()

Which is (simplistically) equivalent to the following:

class MyManager(models.Manager):
  use_for_related_fields = True

  def get_queryset(self, *args, **kwargs):
    return super(MyManager, self).get_queryset(*args, **kwargs).defer("enormous_field")

class MyModel(models.Model):
   enormous_field = models.TextField()
   other_field = models.IntegerField()

   objects = MyManager()

Obviously, you can still do MyModel.objects.defer(None) to do the full query.

Change History (12)

comment:1 by Akis Kesoglou, 10 years ago

I find this really useful, as most of the times you (myself actually, assuming most people too) really don't make a manager just for this optimisation. So defining deferred fields at model level makes sense for me. Though I would prefer to specify the fields in the model's Meta options, as a list of field names, similar to unique_together option.

comment:2 by Akis Kesoglou, 10 years ago

Cc: akiskesoglou@… added

comment:3 by Tim Graham, 10 years ago

Triage Stage: UnreviewedAccepted

I am a little hesitant to accept since there is already a way to accomplish this, but tentatively accepting so we can see what a patch looks like and someone else really like the idea.

Version 0, edited 10 years ago by Tim Graham (next)

comment:4 by Carl Meyer, 10 years ago

I'm also hesitant about adding something that's already doable via a custom manager; I'm probably -0.

If we do it, it should definitely be a Meta option, not a field arg, IMO. It applies to fields, but it's really a characteristic of querying on the model class, not inherently of the Field.

comment:5 by Akis Kesoglou, 10 years ago

I'm inclined to have a go at this. Here's how I envision it:

class Post(models.Model):
    body_text = models.TextField()
    body_html = models.TextField(blank=True)

    class Meta:
        initially_deferred_fields = ('body_text', 'body_html')

Some thoughts:

  • Not sure about the name of the meta attribute, it requires almost as much effort to get the spelling right as creating a custom manager, but I'd like to avoid naming it defer or deferred_fields. I'd like input on this, but it's not pressing.
  • The patch author should be aware of the model meta refactor, perhaps beginning work after it lands?

comment:6 by Will Stott, 9 years ago

I can see a use for this. Currently using a manager which looks at auto_defer (on the manager due to 5793).

class AutoDeferManagerMixin(object):
    use_for_related_fields = True
    auto_defer = tuple()

    def get_queryset(self, *args, **kwargs):
        return super(AutoDeferManagerMixin, self).get_queryset(*args, **kwargs).defer(*self.auto_defer)

comment:7 by Denis.Tarykin, 7 years ago

Owner: changed from nobody to Denis.Tarykin
Status: newassigned

comment:9 by Carlton Gibson, 7 years ago

Patch needs improvement: set

Marking "Patch needs improvement" pending comments on PR

comment:10 by Mariusz Felisiak, 3 years ago

#24096 was a duplicate.

comment:11 by Carlos Palol, 3 years ago

Cc: Carlos Palol added

comment:12 by Mariusz Felisiak, 3 years ago

Resolution: wontfix
Status: assignedclosed
Triage Stage: AcceptedUnreviewed

This ticket was tentatively accepted and we have several opinions against its implementation (Carl, Simon, Adam, we can add me to this list).

Marking as "wontfix", because it seems we need to reach a consensus on the DevelopersMailingList before moving forward. Please follow the triaging guidelines with regards to wontfix tickets and take this to DevelopersMailingList to reach a wider audience and see what other think.

Note: See TracTickets for help on using tickets.
Back to Top