#20625: Custom Chainable QuerySets
-------------------------------------+-------------------------------------
     Reporter:  danols               |                    Owner:  danols
         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                    |
-------------------------------------+-------------------------------------
Changes (by loic84):

 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * needs_docs:  0 => 1


Comment:

 I've tried to come up with a strategy to deprecate all the legacy proxy
 methods.

 The issue at hand is custom managers in the wild that call `super` in
 overridden methods.

 @charettes mentioned on IRC that `__getattribute__` would enable calls to
 `super` but that we wouldn’t be able to differentiate a normal access
 (which shouldn't go through the legacy method) and calls to `super` which
 should trigger the deprecation warning.

 We could have a metaclass, similar to `RenameMethodsBase` which adds back
 legacy methods for every method with the same name in the MRO: if our
 method is ever called (by `super`) we trigger the deprecation warning.

 I ran into a problem when trying to deprecate `Manager.create()` and
 `Manager.get_or_create()` with `RelatedManager` (and similar):

 https://gist.github.com/loic/5861660
 
https://github.com/django/django/blob/master/tests/multiple_database/tests.py#L907-L921

 If `RelatedManager` doesn't call ` super`, we'll never reach custom
 managers' `create()` and `get_or_create()`. I don't see a solution to that
 other than making a backward incompatible change. Or we could elect a few
 proxy methods that shouldn’t be deprecated (like `Manager.all()`, see
 comment in the patch).

 Any suggestions?

 If we can't reach consensus on the deprecation plan I suggest we move on
 with this ticket and open a new one regarding the deprecation itself.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/20625#comment:15>
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.1552c66e3ac08111b9e86d76b039f302%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to