Code

Opened 5 years ago

Closed 5 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: UI/UX:

Description

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
  try:
    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

Attachments (0)

Change History (4)

comment:1 Changed 5 years ago by kmtracey

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 Changed 5 years ago by fero

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 Changed 5 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:4 Changed 5 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.