Support ForeignKey based model inheritance

[James Pic]

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

[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.

[Carlton Gibson]

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 ​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".

[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