Opened 3 years ago

Closed 3 years ago

#18686 closed Uncategorized (duplicate)

Models with same name and common subpackage name clash

Reported by: jason.yates@… Owned by: nobody
Component: Database layer (models, ORM) Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

In the following example, Test is an empty model declared in both base/a/test/models.py and base/b/test/models2.py:

from base.a.test.models import Test
from base.b.test.models2 import Test as Test2

Test.__module__ # prints com.a.test.models
Test2.__module__ # prints com.a.test.models, but should print base.b.test.models2

It appears that the commonly named 'test' subpackage in both 'base.a' and 'base.b' is the issue. Renaming either subpackage causes the issue to disappear.

# models.py/models2.py
from django.db import models
class Test(models.Model): pass

Change History (1)

comment:1 Changed 3 years ago by ptone

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to duplicate
  • Status changed from new to closed

This is a result of the models being associated with an implicit app_label that is derived from the path to the model.

because the app label namespace is flat, a subsequent attempt to import a model named "test" for an app with the label "test" will first check the appcache and return an existing model matching that pair of identifiers. This is a case of clashing app names/labels and as such is a duplicate of #3591

The real bug here is that no error is raised (in Django 1.4) with the following in installed_apps:

'base.a.miscapp',
'base.b.miscapp',
...

this results in two applications with the same label - which will confound the model registration process - such a case should raise an error pointing out the collision early on.

Note: See TracTickets for help on using tickets.
Back to Top