Re: [Django] #10961: Allow users to override forward and reverse relationships on proxy models with !ForeignKey fields.
Django
with !ForeignKey fields.
-------------------------------------+-------------------------------------
Reporter: mrmachine | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: proxy ForeignKey | Needs documentation: 0
reverse relationship manager | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by akaariai):
* stage: Design decision needed => Accepted
Comment:
I am marking this as accepted, I am not sure what is the best approach to
solve this issue, but ability to customize proxy model relations seems
like a good idea (as well as the override help_text idea, too).
--
Ticket URL: <https://code.djangoproject.com/ticket/10961#comment:7>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
with !ForeignKey fields.
-------------------------------------+-------------------------------------
Reporter: mrmachine | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: proxy ForeignKey | Needs documentation: 0
reverse relationship manager | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by pjdelport):
This would definitely be useful.
For my use case, my workaround is to reset the fields to customized
versions after the proxy classes are defined.
For example:
{{{#!python
StateProxy.add_to_class('country', models.ForeignKey(CountryProxy))
RegionProxy.add_to_class('state', models.ForeignKey(StateProxy))
SuburbProxy.add_to_class('region', models.ForeignKey(RegionProxy))
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/10961#comment:8>
Django
with !ForeignKey fields.
-------------------------------------+-------------------------------------
Reporter: mrmachine | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: proxy ForeignKey | Needs documentation: 0
reverse relationship manager | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
* cc: rhertzog (added)
Comment:
pjdelport, this doesn't seem to be enough to update the related fields
(eg. country.state_set). There's a discussion of this on
http://stackoverflow.com/questions/3891880/django-proxy-model-and-
foreignkey and for my needs I have also added something like this:
{{{
#!python
class CountryProxy(Country):
...
@property
def state_set(self):
qs = super(CountryProxy, self).state_set
qs.model = StateProxy
return qs
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/10961#comment:9>
Django
with !ForeignKey fields.
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Keywords: proxy ForeignKey | Triage Stage: Accepted
reverse relationship manager |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by fgregg):
This approach looks interesting. Would something like this be a possible
way forward?
https://schinckel.net/2015/05/13/django-proxy-model-relations/
--
Ticket URL: <https://code.djangoproject.com/ticket/10961#comment:10>
Django
with !ForeignKey fields.
-------------------------------------+-------------------------------------
Reporter: Tai Lee | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: proxy ForeignKey | Triage Stage: Accepted
reverse relationship manager |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Julien Enselme (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/10961#comment:11>
Django
with !ForeignKey fields.
-------------------------------------+-------------------------------------
Reporter: Tai Lee | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: proxy ForeignKey | Triage Stage: Accepted
reverse relationship manager |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Nate Dudenhoeffer):
Forest Gregg has updated the code from his comment for django 2
compatibility here: https://github.com/datamade/django-proxy-overrides
I am beginning to use this, and it seems like a workable approach, but
native support shouldn't require this "late binding" IMHO.
--
Ticket URL: <https://code.djangoproject.com/ticket/10961#comment:12>
Django
with !ForeignKey fields.
-------------------------------------+-------------------------------------
Reporter: Tai Lee | Owner: nobody
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: proxy ForeignKey | Triage Stage: Accepted
reverse relationship manager |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by powderflask):
I've run up against this issue on several projects, in fact nearly every
time I use proxy models to solve a problem. Different workarounds each
time, depending on use-case.
Currently working with M2M relations on proxy models, same issue can
occur.
This is solved nicely with prefetch_related using a Prefetch object, and
specifying the queryset from the related proxy model.
{{{
prefetch=models.Prefetch('related_set',
queryset=RelatedProxyModel.objects.all())
obj = MyModel.objects.prefetch_related(prefetch).first()
assert all( [type(r) == RelatedProxyModel for r in obj.related_set.all()]
)
}}}
The same approach should work for accessing a reverse relation.
This can all be hidden in a model Manager or Queryset to make code
prettier.
Got me to wonder if a similar approach could be used by allowing a
queryset to be specified on select_related? In fact, only need the model
class, since a queryset for select_related would over-specify.
Not as elegant as a declaration on the model, but seems like it might be
pretty flexible and if it's easy to implement, a quick-and-dirty work-
around that avoids any hackery.
--
Ticket URL: <https://code.djangoproject.com/ticket/10961#comment:13>
Django
with !ForeignKey fields.
-------------------------------------+-------------------------------------
Reporter: Tai Lee | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: proxy ForeignKey | Triage Stage: Accepted
reverse relationship manager |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by powderflask):
Re: https://github.com/datamade/django-proxy-overrides
This approach seems to fail when using `.select_related('related')`, where
'related' field is defined with a proxy override.
This is counter intuitive, since `myProxyInstance.related` returns a
different type of object depending on whether the original queryset used
`.select_related` or not.
Hope its useful to document that here.
--
Ticket URL: <https://code.djangoproject.com/ticket/10961#comment:14>
Django
with !ForeignKey fields.
-------------------------------------+-------------------------------------
Reporter: Tai Lee | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: proxy ForeignKey | Triage Stage: Accepted
reverse relationship manager |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by powderflask):
For others who land here looking for solutions...
IF there is a field on your model that can be used to determine which
Proxy subclass to initialize, this approach works beautifully:
https://schinckel.net/2013/06/13/django-proxy-model-state-machine/
No fuss, no overhead, every concrete object gets its correct proxy
subclass type. Limited use-case, but a nifty solution if you happen to
have it.
--
Ticket URL: <https://code.djangoproject.com/ticket/10961#comment:15>
Django
with !ForeignKey fields.
-------------------------------------+-------------------------------------
Reporter: Tai Lee | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: proxy ForeignKey | Triage Stage: Accepted
reverse relationship manager |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Dmytro Litvinov (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/10961#comment:16>
Django
with !ForeignKey fields.
-------------------------------------+-------------------------------------
Reporter: Tai Lee | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: proxy ForeignKey | Triage Stage: Accepted
reverse relationship manager |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: ivanov17 (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/10961#comment:17>