Estoy tratando de dividir el models.py
de mi aplicación en varios archivos:
Mi primera suposición fue hacer esto:
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
Esto no funciona, luego encontré esto , pero en esta solución todavía tengo un problema, cuando ejecuto python manage.py sqlall app1
tengo algo como:
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;
No estoy muy seguro de esto, pero estoy preocupado por la parte The following references should be added but depend on non-existent tables:
Este es mi archivo model1.py:
from django.db import models
class Store(models.Model):
class Meta:
app_label = "store"
Este es mi archivo 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"
Y aparentemente funciona, pero recibí el comentario alter table
y si intento esto, sucede lo mismo:
class Product(models.Model):
store = models.ForeignKey('store.Store')
class Meta:
app_label = "product"
Entonces, ¿debería ejecutar el alter para referencias manualmente? esto puede traerme problemas con el sur?
python
django
django-models
import
diegueus9
fuente
fuente
from app1.models.model1 import Store
?Respuestas:
Haría lo siguiente:
Entonces
#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 *
Pero, si no tiene una buena razón, coloque model1 y model2 directamente en app1 / models.py y model3 y model4 en app2 / models.py
---segunda parte---
Este es el archivo app1 / submodels / model1.py:
from django.db import models class Store(models.Model): class Meta: app_label = "store"
Por lo tanto, corrija su archivo model3.py:
from django.db import models from app1.models import Store class Product(models.Model): store = models.ForeignKey(Store) class Meta: app_label = "product"
Editado, en caso de que esto vuelva a surgir para alguien: consulte django-schedule para ver un ejemplo de un proyecto que hace exactamente esto. https://github.com/thauber/django-schedule/tree/master/schedule/models https://github.com/thauber/django-schedule/
fuente
from product.models import Product
: ImportError: Ningún módulo llamado modelosmodels.py
archivo masivo . Recientemente hice esto cuando el mío creció a más de 15k líneas de código. Sin embargo, gran reseña. El proceso es bastante sencillo. La principal advertencia es que debes recordar definir un app_label explícito, ya que Django lo extrae del módulo inmediato de forma predeterminada.__init__.py
y todo parece estar funcionando bien. No tuve que corregir mis archivos de modelo. Puedo buscar y crear objetos desde el shell y el administrador de django. He estado probando django durante una semana, así que me pregunto si la versión más nueva ahora permite que esto suceda.Para cualquiera en Django 1.9, ahora es compatible con el marco sin definir los metadatos de la clase.
https://docs.djangoproject.com/en/1.9/topics/db/models/#organizing-models-in-a-package
NOTA: Para Django 2, sigue siendo el mismo
Entonces, en su caso, para una estructura como
Solo necesitas hacer
#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
Una nota contra la importación de todas las clases:
fuente
models.py
y desea migrar más tarde. En ese caso, debe eliminar sus migraciones y su base de datos: / O resolver manualmente todos los errores en todos los archivos de migraciónDe hecho, me encontré con un tutorial para exactamente lo que está preguntando, puede verlo aquí:
http://paltman.com/breaking-apart-models-in-django/
Un punto clave que probablemente sea relevante: es posible que desee utilizar el campo db_table en la clase Meta para señalar las clases reubicadas de nuevo en su propia tabla.
Puedo confirmar que este enfoque está funcionando en Django 1.3
fuente
Pasos más sencillos:
__init__.py from django_adminlte.models.employee import Employee
model/employee.py (employee is separate model file) from django.db import models class Employee(models.Model): eid = models.CharField(max_length=20) ename = models.CharField(max_length=20) eemail = models.EmailField() econtact = models.CharField(max_length=15) class Meta: db_table = "employee" # app_label = 'django_adminlte' def __str__(self): return self.ename
fuente
RuntimeError ModelX doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS.
en django 2.x.Escribí un guión que podría ser útil.
github.com/victorqribeiro/splitDjangoModels
dividió los modelos en archivos individuales con el nombre y la importación adecuados; también crea un archivo de inicio para que pueda importar todos sus modelos a la vez.
Déjeme saber si esto ayuda
fuente