[Django] #29691: Support ForeignKey based model inheritance
Django
-------------------------------------+-------------------------------------
Reporter: James Pic | Owner: nobody
Type: New | Status: new
feature |
Component: Database | Version: 2.1
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Currently, a model inheriting another will have a 1:1 relation with an
automatically managed OneToOneField. This means a parent model instance
may only have one child model instance. However, sometimes it may be
interresting to have several child model instances for one parent model
instance.
For example, creating a new child model with the same parent results in an
error like:
django.db.utils.IntegrityError: UNIQUE constraint failed:
djcall_call.callable_ptr_id
But overriding the parent field with a ForeignKey is not accepted:
django.core.exceptions.FieldError: Auto-generated field
'callable_ptr' in class 'Call' for parent_link to base class 'Callable'
clashes with declared field of the same name.
Can we perhaps add an exception (not Exception!) for child models that
override the automatic ptr field that is a OneToOneField, with a
ForeignKey ?
Thanks
--
Ticket URL: <https://code.djangoproject.com/ticket/29691>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: James Pic | Owner: nobody
Component: Database layer | Version: 2.1
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Old description:
> Currently, a model inheriting another will have a 1:1 relation with an
> automatically managed OneToOneField. This means a parent model instance
> may only have one child model instance. However, sometimes it may be
> interresting to have several child model instances for one parent model
> instance.
>
> For example, creating a new child model with the same parent results in
> an error like:
>
> django.db.utils.IntegrityError: UNIQUE constraint failed:
> djcall_call.callable_ptr_id
>
> But overriding the parent field with a ForeignKey is not accepted:
>
> django.core.exceptions.FieldError: Auto-generated field
> 'callable_ptr' in class 'Call' for parent_link to base class 'Callable'
> clashes with declared field of the same name.
>
> Can we perhaps add an exception (not Exception!) for child models that
> override the automatic ptr field that is a OneToOneField, with a
> ForeignKey ?
>
> Thanks
New description:
Currently, a model inheriting another will have a 1:1 relation with an
automatically managed OneToOneField. This means a parent model instance
may only have one child model instance. However, sometimes it may be
interresting to have several child model instances for one parent model
instance.
For example, creating a new child model with the same parent results in an
error like:
django.db.utils.IntegrityError: UNIQUE constraint failed:
djcall_call.callable_ptr_id
But overriding the parent field with a ForeignKey is not accepted:
django.core.exceptions.FieldError: Auto-generated field
'callable_ptr' in class 'Call' for parent_link to base class 'Callable'
clashes with declared field of the same name.
Can we perhaps add an exception (not Exception!) for child models that
override the automatic ptr field that is a OneToOneField, with a
ForeignKey ?
An example use case:
{{{
class Caller(models.Model):
callback = models.CharField()
max_attemps = models.IntegerField(default=1)
def call(self):
call = Call(caller_ptr=self)
try:
call.execute()
except:
if self.max_attempts > Call.objects.filter(caller_ptr=self):
return self.call()
raise
return call.result
class Call(Caller):
result = models.PickleField()
def call(self):
self.result = import_string(self.callback)()
return self.result
}}}
Thanks
--
--
Ticket URL: <https://code.djangoproject.com/ticket/29691#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: James Pic | Owner: nobody
Component: Database layer | Version: 2.1
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Tim Graham):
I have a feeling that breaking the one-on-one link between parent and
child in model inheritance would add a lot of complexity and bugs. I think
using a ForeignKey without inheritance would be the way to go.
--
Ticket URL: <https://code.djangoproject.com/ticket/29691#comment:2>
Django
-------------------------------------+-------------------------------------
Reporter: James Pic | Owner: nobody
Component: Database layer | Version: 2.1
(models, ORM) |
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => wontfix
Comment:
I strongly suspect that Tim's initial judgement here is correct.
Even if it's not though, changing the way model inheritance works would be
such a big change that I think it would need to go through the whole
[https://github.com/django/deps/blob/master/final/0001-dep-process.rst DEP
process], rather than be something we could just add as a normal ''New
Feature''.
As such, I'm going to close this here. The following step (if any) would
be "Pre-proposal".
--
Ticket URL: <https://code.djangoproject.com/ticket/29691#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: James Pic | Owner: nobody
Component: Database layer | Version: 2.1
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by James Pic):
Thanks a heap for your feedback,
I suppose I could try this by overriding a metaclass, if it works for this
use case i will make a DEP then (to avoid maintaining the pochack accross
stable django releases)
Have a great day
--
Ticket URL: <https://code.djangoproject.com/ticket/29691#comment:4>