Opened 3 years ago

Closed 3 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


In django/db/models/ 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)

18975.diff (1.2 KB) - added by FunkyBob 3 years ago.
Passes on git rev 9db7652

Download all attachments as: .zip

Change History (7)

comment:1 Changed 3 years ago by akaariai

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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

Changed 3 years ago by FunkyBob

Passes on git rev 9db7652

comment:2 Changed 3 years ago by FunkyBob

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 Changed 3 years ago by akaariai

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 Changed 3 years ago by ptone

  • Cc preston@… added

comment:5 Changed 3 years ago by melinath

  • Triage Stage changed from Unreviewed to Design decision needed

This sounds like DDN?

comment:6 Changed 3 years ago by aaugustin

  • Resolution set to wontfix
  • Status changed from new to closed

The backwards-incompatibility looks unavoidable.

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