app1.MyModel: (models.E005) The field 'id' from parent model 'app2.othermodel' clashes with the field 'id' from parent model 'app3.othermodel'
|Reported by:||benjaoming||Owned by:||Tim Graham|
|Severity:||Release blocker||Keywords:||multiple model inheritance|
|Cc:||Tim Graham, Anssi Kääriäinen||Triage Stage:||Accepted|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
The system check framework borks on multiple inheritance due to the 'id' field being the same on two different models, even though that field is IMO not relevant to the child class.
See this issue on django-wiki:
ERRORS: wiki.ArticleSubscription: (models.E005) The field 'id' from parent model 'wiki.articleplugin' clashes with the field 'id' from parent model 'django_notify.subscription'.
Basically, we have app1 creating a model with multiple inheritance from models in app2 and app3. Thus, model fields cannot be renamed from app1 since it has nothing to do with the code base of app2 and app3.
I think it's a simple case of leaving the 'id' field out of the check since it's not inherited to the child model, anyways.
The above model looks like this:
class ArticleSubscription(ArticlePlugin, Subscription): pass
The SQL for creating this (django 1.6 and 1.7)
CREATE TABLE "wiki_articlesubscription" ( "subscription_ptr_id" integer NOT NULL UNIQUE REFERENCES "notify_subscription" ("id"), "articleplugin_ptr_id" integer NOT NULL PRIMARY KEY REFERENCES "wiki_articleplugin" ("id") )
I would suggest skipping the check on 'id' in order to reflect what can be interpreted in the docs and the SQL. In the docs, we can read:
Just as with Python’s subclassing, it’s possible for a Django model to inherit from multiple parent models. Keep in mind that normal Python name resolution rules apply. The first base class that a particular name (e.g. Meta) appears in will be the one that is used; for example, this means that if multiple parents contain a Meta class, only the first one is going to be used, and all others will be ignored.
...and in the SQL, we see that the PK of the first model is chosen as primary key. Thus, if the child model retains an id field proxy that references the first models PK (in this case, articleplugin_ptr_id), everything is fine! And in the docs, we can add that inheriting from a non-abstract model will always reference the id field of the child to the first parent models PK (as with the Meta class!).