Сплит models.py в несколько файлов
Я пытаюсь разделить models.py
моего приложения в несколько файлов:
моя первая догадка была сделать это:
myproject/
settings.py
manage.py
urls.py
__init__.py
app1/
views.py
__init__.py
models/
__init__.py
model1.py
model2.py
app2/
views.py
__init__.py
models/
__init__.py
model3.py
model4.py
это не работает, то я нашел этой, но в этом решении у меня все еще есть проблема, когда я запускаю python manage.py sqlall app1
я получил что-то вроде:
BEGIN;
CREATE TABLE "product_product" (
"id" serial NOT NULL PRIMARY KEY,
"store_id" integer NOT NULL
)
;
-- The following references should be added but depend on non-existent tables:
-- ALTER TABLE "product_product" ADD CONSTRAINT "store_id_refs_id_3e117eef" FOREIGN KEY ("store_id") REFERENCES "store_store" ("id") DEFERRABLE INITIALLY DEFERRED;
CREATE INDEX "product_product_store_id" ON "product_product" ("store_id");
COMMIT;
Я не уверен в этом, но я беспокоюсь о Часть The following references should be added but depend on non-existent tables:
это мой model1.py файл:
from django.db import models
class Store(models.Model):
class Meta:
app_label = "store"
это мой model3.py файл:
from django.db import models
from store.models import Store
class Product(models.Model):
store = models.ForeignKey(Store)
class Meta:
app_label = "product"
и, видимо, работает, но я получил комментарий, в alter table
и если я попробую это, то же самое происходит:
class Product(models.Model):
store = models.ForeignKey('store.Store')
class Meta:
app_label = "product"
Итак, я должен запустить alter for references вручную? это может принести мне проблемы с Югом?
3 ответа:
Я даже не могу себе представить, почему вы хотите это сделать. Но я предполагаю, что у вас есть веская причина. Если бы мне нужно было сделать это по какой-то причине, я бы сделал следующее:
myproject/ ... app1/ views.py __init__.py models.py submodels/ __init__.py model1.py model2.py app2/ views.py __init__.py models.py submodels/ __init__.py model3.py model4.py
затем
#myproject/app1/models.py: from submodels/model1.py import * from submodels/model2.py import * #myproject/app2/models.py: from submodels/model3.py import * from submodels/model4.py import *
но, если у вас нет веской причины, поместите model1 и model2 непосредственно в app1/models.py и model3 и model4 в app2/models.py
---вторая часть---
это app1/submodels/model1.py файл:
исправить model3 file:from django.db import models class Store(models.Model): class Meta: app_label = "store"
from django.db import models from app1.models import Store class Product(models.Model): store = models.ForeignKey(Store) class Meta: app_label = "product"
отредактировано, если это снова появится для кого-то: Проверьте django-расписание для примера проекта, который делает именно это. https://github.com/thauber/django-schedule/tree/master/schedule/models https://github.com/thauber/django-schedule/
для любого пользователя на Django 1.9 теперь он поддерживается платформой без определения метаданных класса.
https://docs.djangoproject.com/en/1.9/topics/db/models/#organizing-models-in-a-package
Примечание: Для Django 2, это все то же самое
The
manage.py startapp
команда создает структуру приложения, которая включает в себя models.py файл. Если у вас много моделей, организуйте их по отдельности файлы могут быть полезны.для этого создайте пакет моделей. Снять models.py и создать С
__init__.py
файл и файлы для хранения ваших моделей. Вы должны импортировать модели в .Итак, в вашем случае, для такой структуры, как
app1/ views.py __init__.py models/ __init__.py model1.py model2.py app2/ views.py __init__.py models/ __init__.py model3.py model4.py
вам нужно только сделать
#myproject/app1/models/__init__.py: from .model1 import Model1 from .model2 import Model2 #myproject/app2/models/__init__.py: from .model3 import Model3 from .model4 import Model4
Примечание против импорта всех классов:
явный импорт каждой модели вместо использования
from .models import *
имеет преимущества не загромождать пространство имен, что делает код более читаемым и сохраняет инструменты анализа кода полезными.
Я на самом деле наткнулся на учебник именно то, о чем вы спрашиваете, вы можете посмотреть его здесь:
http://paltman.com/breaking-apart-models-in-django/
один ключевой момент, который, вероятно, имеет отношение - вы можете использовать поле db_table в мета-классе, чтобы указать перемещенные классы обратно в их собственную таблицу.
Я могу подтвердить, что этот подход работает в Django 1.3