Opened 12 years ago
Closed 12 years ago
#18975 closed Cleanup/optimization (wontfix)
Remove explicit support for bad practices
Reported by: | FunkyBob | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.4 |
Severity: | Normal | Keywords: | |
Cc: | preston@… | Triage Stage: | Design decision needed |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
In django/db/models/loading.py in AppCache.register_models the comments say:
# The same model may be imported via different paths (e.g.
# appname.models and project.appname.models). We use the source
# filename as a means to detect identity.
Overlapping import paths lead to many unobvious errors -- especially with signals. Explicitly covering for people persisting in this poor behaviour, which the new project layout was supposed to help avoid, is not doing anyone any favours.
Attachments (1)
Change History (7)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
I guess the first issue would be how to detect such a condition...
A variant of the original code could be used so if the models don't match, but their file paths do, it raises an error to says "sloppy, kid"...
comment:3 by , 12 years ago
No, the first issue is to determine if we can actually do anything about this without breaking backwards compat.
We can't raise that error unconditionally. This would break a _lot_ of existing applications, and while they should probably fix their project, it isn't something we can enforce them to do. Even going through deprecation seems hard here, this is not a simple change to do to existing project. In general I have a feeling we might be deprecating a little too much stuff, especially taking in account we don't have long-term releases.
But, yeah, if we get two different class instances with same app-label/model name and same file path that seems to be a sign of doubleimport...
comment:4 by , 12 years ago
Cc: | added |
---|
comment:6 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
The backwards-incompatibility looks unavoidable.
The problem is backwards compatibility - old projects need to work with new version of Django. Do you have some suggestion how we can do something to this without breaking old installations?
We could probably raise a warning at the least, but actually preventing the multiloading seems hard...