#20625: Custom Chainable QuerySets
-------------------------------------+-------------------------------------
     Reporter:  danols               |                    Owner:  loic84
         Type:  New feature          |                   Status:  assigned
    Component:  Database layer       |                  Version:  master
  (models, ORM)                      |               Resolution:
     Severity:  Normal               |             Triage Stage:  Accepted
     Keywords:  QuerySet,            |      Needs documentation:  1
  models.Manager, chainable          |  Patch needs improvement:  1
    Has patch:  1                    |                    UI/UX:  0
  Needs tests:  1                    |
Easy pickings:  0                    |
-------------------------------------+-------------------------------------

Comment (by akaariai):

 I have tried various versions of making Manager a subclass of QuerySet.
 The most promising approach was to use a temporary class for hiding
 QuerySet only functionality from the manager, and drop the temp class on
 first clone. So:
   1. On creation of manager, create a dynamic class and add
 HideQuerySetMethods to the `__bases__` of the dynamic class. Effect is
 that for example .delete() calls HideQuerySetMethods.delete(), not
 QuerySet.delete().
   2. On first clone, switch the class to the original class, that is drop
 the HideQuerySetMethods class from `__bases__`.

 I got the solution to almost working state, but it required too many
 kluges. I ended up deleting the branch as there was just too many little
 problems to make it work cleanly.


 I have seen the idea of this ticket discussed multiple times. Every time
 some solutions are offered, but the solutions always have some problematic
 cases that end up stalling the development effort. I think the solution in
 this ticket is clean, and makes it easy enough to add queryset methods.
 So, my opinion is that we should go forward with it.

 I wouldn't actually remove the proxy methods at all. Removing them doesn't
 seem worth the effort, the maintenance burden of the methods is very
 small. If they are going to be removed, then all must be removed in one
 go. It is just weird if some of the proxy methods are still there because
 Django needs the super() method to be present, but other are removed.

 It seems #17270 is a duplicate, I guess that one could be closed as this
 ticket seems to have more momentum at the moment.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/20625#comment:18>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.d1898c9feb4097414f006674632832e0%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to