python - template - is not a registered tag library. must be one of:

Ciclo de dependencia de la aplicación Django

Question

Estoy desarrollando una aplicación Django, que tiene modelos bastante complicados (modela una universidad: cursos, módulos, conferencias, estudiantes, etc.)

He separado el proyecto en aplicaciones, para que todo esté más organizado (las aplicaciones son cursos, escuelas, personas, módulos y periodos de tiempo). Tengo un problema por el cual un modelo en una aplicación puede depender de un modelo en otra, por lo que debo importarlo. La segunda aplicación, a su vez, depende de un modelo en la primera, por lo que hay un ciclo y Python arroja un error.

¿Cómo trata la gente con esto? Entiendo que las aplicaciones deben ser relativamente "independientes", pero en un sistema como este no tiene sentido, por ejemplo, usar ContentTypes para vincular a los estudiantes con un módulo.

¿Alguien tiene un proyecto similar que pueda comentar sobre este caso?

Answer 1

Es posible que esto no se adapte bien a su situación, pero al ignorar el aspecto de Django de su pregunta, la técnica general para romper las dependencias circulares es dividir uno de los elementos con referencias cruzadas en un nuevo módulo. Por ejemplo:

moduleA: class1, class2
           |        ^
           v        |
moduleB: class3, class4

podría convertirse:

moduleC: class 3
           ^
           |
moduleA: class 1, class 2
                     ^
                     |
moduleB:          class 4

(O alternativamente, podrías haber roto la clase 2 en su propio módulo. ¡O ambos!)

Por supuesto, esto no sirve de nada si las clases A y B dependen unas de otras. En ese caso, tal vez deberían estar en el mismo módulo, o mejor aún, tal vez alguna parte de estas clases podría dividirse en un tercer módulo, del cual dependen ambas clases.

Answer 2

Normalmente abogo por la división de la funcionalidad en aplicaciones más pequeñas, pero una dependencia circular entre los modelos refleja una integración tan estrecha que probablemente no esté ganando mucho con la división y podría considerar fusionar las aplicaciones. Si eso resulta en una aplicación que se siente demasiado grande, puede haber una manera de dividirse a lo largo de un eje diferente, lo que resulta en un gráfico de dependencia más sano.

Answer 3

Si está viendo una dependencia de modelo circular, supongo que está ocurriendo una de tres cosas:

• Ha definido una relación inversa con una que ya está definida (por ejemplo, ambos cursos tienen muchas conferencias y una conferencia tiene un curso) que es redundante en django
• Tienes un método modelo en la aplicación incorrecta
• Está proporcionando funcionalidad en un método modelo que debería estar en un administrador

Tal vez podría mostrarnos lo que está sucediendo en estos modelos y podemos tratar de averiguar por qué surge el problema. La dependencia del modelo circular rara vez es una indicación de que necesita combinar dos aplicaciones; es más probable (aunque no sea el caso) que haya un problema con una de sus definiciones de modelo.

ps. Estoy trabajando en una aplicación de django similar, pero la estructura de mi aplicación es probablemente muy diferente a la suya. Me encantaría ofrecerle una descripción de alto nivel si está interesado.

Answer 4

Si su dependencia es con claves foráneas que hacen referencia a modelos en otras aplicaciones, no necesita importar el otro modelo. Puedes usar una cadena en tu definición de ForeignKey:

class MyModel(models.Model):
    myfield = models.ForeignKey(''myotherapp.MyOtherModel'')

De esta manera no hay necesidad de importar MyOtherModel, por lo que no hay una referencia circular. Django resuelve la cadena internamente, y todo funciona como se espera.