Opened 15 years ago

Closed 15 years ago

#10310 closed (wontfix)

Model attribute default_queryset

Reported by: fero Owned by: nobody
Component: Database layer (models, ORM) Version: 1.0
Severity: Keywords: manager, queryset, enhancement
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


This enhancement aims to make the developer able to use its own specialized queryset
without defining a custom Manager on the model. Custom manager
is usually defined for:

  • custom filtering of default queryset
  • provide methods to perform custom operations on data

I propose to provide Model with a "default_queryset" attribute
to avoid defining the manager in the second case.

The default manager get_query_set() must be modified in order to
return self.model.default_queryset instance instead of
QuerySet one.

Furthermore default manager class must be modified like the following:

def __getattr__(self, attr):
  # Proxy to queryset
    rv = super(.....).__getattr__(...)
  except AttributeError:
    rv = getattr(self.get_query_set(), attr)
  return rv

Example of usage:

class MyQuerySet(QuerySet):

   def m1(self):
       return self.filter(myfield=True)
   def m2(self):
       return self.exclude(myfield2__gte=10)

class MyModel(models.Model):
   default_queryset = MyQuerySet

If you are interested in this feature I can make a patch

Change History (4)

comment:1 by Karen Tracey, 15 years ago

The motivation for this is unclear to me. Why would we want a 2nd way to do something that is already possible? That just seems confusing. What is the problem with defining a custom Manager that is solved by this approach?

comment:2 by fero, 15 years ago

There is no really a need, but likely there is no need of any other "shortcut".

Avoiding a developer to define its own Manager for each QuerySet he has to define,
encourage him to manage his data in a much more "polite" way.

Furthermore it is very useful to do default_queryset overriding for views of different applications
relying on the same model, or same application providing different data views (I mean db views)
to different users.

<passed-some-time studying django code>

Actually I don't see why developers should care knowing about Manager classes.
Manager are useful for django developers, but maybe ordinary developers should care
only about overriding querysets, not managers.

The get_query_set() method could be implemented in the MyQuerySet.init method.
Developers could simpy bind 'objects' to 'default_queryset' and 'myobjects' to 'myqueryset'.

Ok. Probably this problem has to be discussed in mailing-list before proceeding with this ticket.
Thank you for your time...

Maybe you are right: this is not really useful if you don't make "queryset overriding"
the preferred way to specialize your db-views.

comment:3 by (none), 15 years ago

milestone: post-1.0

Milestone post-1.0 deleted

comment:4 by Jacob, 15 years ago

Resolution: wontfix
Status: newclosed

This is Python: "there should be one obvious way to do things."

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