2011-06-13 10 views
49

Estoy tratando de dividir el models.py de mi aplicación en varios archivos:models.py dividirse en varios archivos

Mi primera suposición era 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, entonces i encontrado this, pero en esta solución todavía tengo un problema, cuando corro python manage.py sqlall app1 tengo algo así 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 me preocupa una boout 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 al parecer funciona, pero me dieron el comentario en 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 Ejecuto el alter para referencias manualmente? esto puede traerme problemas con el sur?

+0

¿Qué sucede en el modelo 3 si intenta 'from app1.models.model1 import Store'? –

+0

También es posible que desee comprobar http://stackoverflow.com/questions/5534206/how-do-i-separate-my-models-out-in-django/5534251#5534251 –

Respuesta

23

No puedo ni siquiera empezar a imaginar por qué querrías hacer esto. Pero supongo que tienes una buena razón. Si necesitaba hacer esto por alguna razón, me gustaría hacer lo siguiente:

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 

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 usted no tiene una buena razón, pone model1 y model2 directamente app1/models.py y MODEL3 y model4 en app2/models.py

--- --- segunda parte

Esta es app1/submodelos/model1.py archivo:

from django.db import models 
class Store(models.Model): 
    class Meta: 
     app_label = "store" 

De este modo corregir su archivo MODEL3:

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 viene de nuevo para alguien: Salida django-horario para un ejemplo de un proyecto que hace precisamente esto. https://github.com/thauber/django-schedule/tree/master/schedule/models https://github.com/thauber/django-schedule/

+1

Con respecto a esta respuesta obtuve otra problema cuando en models2.py crea algo como 'from product.models import Product': ImportError: ningún módulo llamado modelos – diegueus9

+0

de appx.models import Product – Ted

+29

lo haría de esta manera para mantener una clase por archivo. – worc

11

De hecho, he encontrado con un tutorial para exactamente lo que estás preguntando, se puede ver aquí:

http://paltman.com/breaking-apart-models-in-django/

Un punto clave que probablemente es relevante - es posible que desee usar el campo db_table en la clase Meta para señalar las clases reubicadas en su propia tabla.

puedo confirmar este enfoque está trabajando en Django 1.3

+0

Ese enlace da un 404 –

+0

Parece que lo movió a http://paltman.com/breaking-apart-models-in-django/ –

63

para cualquier persona en Django 1.9, ahora se apoya en el marco, sin definir los metadatos de clase.

https://docs.djangoproject.com/en/1.9/topics/db/models/#organizing-models-in-a-package

The manage.py startapp command creates an application structure that includes a models.py file. If you have many models, organizing them in separate files may be useful.

To do so, create a models package. Remove models.py and create a myapp/models/ directory with an __init__.py file and the files to store your models. You must import the models in the __init__.py file.

Así, en su caso, por una estructura como

app1/ 
    views.py 
    __init__.py 
    models/ 
     __init__.py 
     model1.py 
     model2.py 
app2/ 
    views.py 
    __init__.py 
    models/ 
     __init__.py 
     model3.py 
     model4.py 

Sólo es necesario 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:

Explicitly importing each model rather than using from .models import * has the advantages of not cluttering the namespace, making code more readable, and keeping code analysis tools useful.