Opened 17 years ago

Closed 17 years ago

Last modified 10 years ago

#2982 closed enhancement (duplicate)

[patch] allow replacing models.py with a subpackage models/__init__.py

Reported by: Bastian Kleineidam <calvin@…> Owned by: nobody
Component: Database layer (models, ORM) Version:
Severity: normal Keywords:
Cc: ferringb@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

Hi,

if you have a lot of models, or even a model hierarchy, one might want to convert the plain models.py into a package models/__init__.py.
However, the ModelBase class cannot cope with models in subpackages, since it always chooses the second-last module part as app name. This patch fixes this by looking for the module part before models.

Attachments (2)

django_models.diff (1.1 KB ) - added by Bastian Kleineidam <calvin@…> 17 years ago.
model-api.diff (995 bytes ) - added by Marc Fargas <telenieko@…> 17 years ago.
Documentation for #2982

Download all attachments as: .zip

Change History (13)

by Bastian Kleineidam <calvin@…>, 17 years ago

Attachment: django_models.diff added

comment:1 by anonymous, 17 years ago

Summary: allow replacing models.py with a subpackage models/__init__.py[patch] allow replacing models.py with a subpackage models/__init__.py

comment:2 by James Bennett, 17 years ago

I don't know offhand if it's documented anywhere (if it isn't we need to fix that), but splitting models up into files in a module actually works right now -- you just have to set the Meta option app_label to the name of the app, and make sure the __all__ statement in the module's __init__.py exports all the files you want to use.

comment:3 by Gary Wilson <gary.wilson@…>, 17 years ago

There is some documentation at CookBookSplitModelsToFiles.

There used to be a small section in the old model_api docs, but that seems to have disappeared.

comment:4 by Bastian Kleineidam <calvin@…>, 17 years ago

I did not see the Meta.app_name setting. With the patch you don't need to set the Meta.app_name anymore. Just move the Models in a subpackage and be done.

And it would be nice to have the models-as-subpackage doc paragraph back, I surely missed that :)

comment:5 by Chris Beaven, 17 years ago

Needs documentation: set
Triage Stage: UnreviewedReady for checkin

Looking good, Bastian.

Some documentation could be good, but I don't think it blocks this being checked in.

comment:6 by Marc Fargas <telenieko@…>, 17 years ago

Triage Stage: Ready for checkinAccepted

Stripping the "Ready for checking" as I'm about to upload documentation for that, please review it and set "Ready for checking" if it's ok.

Hope you don't mind ;)

by Marc Fargas <telenieko@…>, 17 years ago

Attachment: model-api.diff added

Documentation for #2982

comment:7 by Chris Beaven, 17 years ago

Needs documentation: unset
Triage Stage: AcceptedReady for checkin

Apart from a few weird character typos in the documentation, it looks all right to me. I'm sure a core will check the wording / typos and change as appropriate.

comment:8 by anonymous, 17 years ago

Needs tests: set
Patch needs improvement: set
Triage Stage: Ready for checkinAccepted

Not quite ready for checkin yet, upon examination (no fault of the triagers, I just was looking over it before checking it in)...

In the past we've rejected this sort of approach because it required the redundant import statements in models/__init__.py (rather than just from models.foo.bar import MyModel in the code being sufficient). Ideally, it would be nice to descend from models (whether it's models/ or models.py) and extract all the models without needing the models/__init__.py import. I think db.models.loading is one place that needs fixing for that. I think it should be possible to make this work.

We should be able to make a test for this one, since we have models.py files in the tests already (make a new test directory and have a models/ directory in it). Need to make sure we test that it works sufficiently generally (models/foo/bar.py should work -- looks like it does, but testing makes perfect).

I don't like the use of "assert" in this patch, since assert is for things that should never fail and we can "guarantee" will be true. We cannot make guarantees about the user's (programmer's) code, though; they do make mistake and it's not Django's internal fault if that happens. So we should do a normal check and raise a proper exception (not AssertionError) if there is a problem. Everywhere else in Django does this upon an end-user error, so it's consistent.

I'll probably fix some/all of these problems myself on the next pass through if nobody wants to do it first. Just recording the problems for future triage benefit.

comment:9 by (removed), 17 years ago

Cc: ferringb@… added

comment:10 by James Bennett, 17 years ago

Resolution: duplicate
Status: newclosed

This is yet another issue related to app_label, and so gets closed in favor of #3591.

comment:11 by Aymeric Augustin, 10 years ago

Easy pickings: unset
UI/UX: unset

This is actually a duplicate of #14007 which was fixed in [2333c966].

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