#4470 closed Uncategorized (duplicate)
Separate models.py in multiple files
| Reported by: | Owned by: | nobody | |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Normal | Keywords: | models |
| Cc: | brosner@…, drackett@…, gabor@…, camillobruni@… | Triage Stage: | Design decision needed |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | yes | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
I want to separate my models file (models.py) into multiple files : Product.py, Category.py, .... , which will be set up in the models directory. That´s to say:
+ myapp/ + models/ |- __init__.py |- Product.py |- Category.py |- Media.py |- ...
Since models is a module, we have to add the file init.py:
from Product import Product from Category import Category ....
When doing, there are some actions from manage.py related to models that will not work.
It can be fixed, by associating models explicitly to the application :
class Product(models.Model):
...
class Meta:
app_label = 'myapp'
The app_label is deducted from the name of model module (django/db/models/base.py, ):
new_class._meta.app_label = model_module.__name__.split('.')[-2]
So when the model module name is myproject.myapp.models.product, the app_label deducted is models and not myapp, and this is
why manage.py syndb doesnt work for example.
I suggest to change it:
module_name = model_module.__name__.split('.')
new_class._meta.app_label = module_name[module_name.index('models')-1]
it works perfectly in the both cases.
Attachments (3)
Change History (23)
by , 18 years ago
| Attachment: | separates_models.diff added |
|---|
comment:1 by , 18 years ago
| Needs tests: | set |
|---|---|
| Triage Stage: | Unreviewed → Design decision needed |
comment:2 by , 18 years ago
I second this idea, because it also helps in cases where Django models are being used outside of a Django application (I do this frequently at my job).
comment:3 by , 18 years ago
| Cc: | added |
|---|
comment:4 by , 17 years ago
| Cc: | added; removed |
|---|
+1 vote for this and would go so far as saying that everyone should do it. Means you can view what domain objects your application has at a glance through the file systems. Great for finding things :-)
comment:5 by , 17 years ago
| Cc: | added |
|---|
track is dumb sometimes... (or maybe I should learn how to use it)
comment:6 by , 17 years ago
comment:7 by , 17 years ago
Ignore previous comment. Typo on my part -- should have referred to #4770.
comment:9 by , 17 years ago
I would love to be able to split my models. Currently I am using models.py to import from my separated models.
# models.py
import book, author
class Book(book.Book):
pass
class Author(author.Author):
pass
follow-up: 12 comment:10 by , 17 years ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
Since I'm almost 100% certain that the eventual solution to #3591 will solve this, I'm marking as a duplicate.
comment:11 by , 17 years ago
I just read the statment (two comments above) from lee.a.connell@…
You don't need to subclass the classes you imported:
http://www.djangoproject.com/documentation/model-api/#models-across-files
from mysite.geography.models import ZipCode
class Restaurant(models.Model):
# ...
zip_code = models.ForeignKey(ZipCode)
comment:12 by , 17 years ago
Replying to ubernostrum:
Since I'm almost 100% certain that the eventual solution to #3591 will solve this, I'm marking as a duplicate.
I can't see how #3591 would fix this issue.
#3591 is about giving applications custom names.
This ticket is about being able to split models for a particular app into separate files. That doesn't have much to do with naming applications. Consider an unnamed application (in terms of #3591, "the old syntax app definition") and models split into models/*.py. With the latest trunk code ([7739], to be certain), that misleads ORM which starts looking for tables named models_<model>, not <app>_<model>.
I also can't understand very little interest from the public. Everyone is actually happy having all their models in a single file? Don't you agree that models.py becomes hardly maintanble even with half a dozen of non-trivial models?
By the way, Django developers themselves use the same approach in many places:
# Contents of django/newforms/__init__.py from widgets import * from fields import * from forms import * from models import * # Nothing more! All entites gracefully split into subpackages.
Why not allow Django users to follow the same way for their models?
comment:13 by , 17 years ago
You can split up models, right now. It's just that the mechanism for doing so depends on app_label and therefore is more fragile than it needs to be. Thus, fixing app_label will, as a side effect, make this not be so fragile anymore, which means this really is a duplicate of #3591 because it refers to the same underlying issue.
comment:14 by , 16 years ago
by , 16 years ago
| Attachment: | separate_models.7835.diff added |
|---|
New patch which works after [7777] models refactoring
by , 16 years ago
| Attachment: | separate_models.9107.diff added |
|---|
Revision bump (just in case if some 1.0 newbie suddenly realizes he can't split models.py without copy-pasting app_label to each and every class)
comment:15 by , 16 years ago
| Cc: | added |
|---|
comment:16 by , 16 years ago
| Cc: | added |
|---|
comment:17 by , 15 years ago
| Cc: | added |
|---|
comment:18 by , 15 years ago
I agree with semenov; Django does split big modules under a package--check out how Django's own models are split under a package with a separate field module for model fields:
+ models/ |- fields/ # Fields broken into several modules too |- __init__.py # Models go here |- manager.py # Manager goes here |- ...
This can be done right now without patching Django, with the exception that you must have the models.py module and the package cannot be named models.
+ myapp/ + _models/ |- __init__.py # Models go here |- fields.py # Custom model fields |- managers.py # Custom managers |- model_group.py # If you have some specialized models that can be grouped together to split the bloat from __init__.py |- validators.py # When you have more than half a dozen |- ... + models.py # Imports all the relevant bits from _models
comment:20 by , 11 years ago
| Easy pickings: | unset |
|---|---|
| Severity: | → Normal |
| Type: | → Uncategorized |
| UI/UX: | unset |
This is actually a duplicate of #14007 which was fixed in [2333c966].
This is actually a reasonable solution, no more hackish than it already is and saves the work-around step of having to provide
app_labelfor all your split models.I can't see a downside, but since it is quite core I'll move to design decision.
I guess some model tests could be written for split models to show it working still.