2012-05-24 15 views
7

Antecedentes: Tengo 5 proyectos independientes de Django que estoy intentando combinar en 1 proyecto de Django compuesto por varias aplicaciones. En otras palabras: projA tiene appA, projB tiene appB & projC tiene appC, etc. Quiero 1 masterProj que tenga appA, appB & appC.Usando la autenticación de usuario django y taggit para múltiples aplicaciones en un solo proyecto

Actualmente, cada aplicación se conecta a su propia base de datos independiente (las aplicaciones no comparten datos). Cada proyecto utiliza autenticación de usuario de Django, registro de Django, taggit, perfiles, comentarios y miniatura de sorl.

Estoy usando Django 1.4 y configuré database routing according to this stackoverflow answer para que, una vez combinados en un solo proyecto, cada aplicación en el nuevo proyecto Django aún pueda conectarse a su propia base de datos. Que transcurrió sin problemas, pero empezó a tener problemas con cosas como la autenticación de usuarios y Taggit:

1) Como se ha mencionado antes, cada aplicación se conecta a una base de datos diferente y cada una de esas bases de datos tiene una tabla llamada 'auth_user'. Sin embargo, he encontrado que todos lectura/escritura llamadas a la mesa auth_user (independientemente de la aplicación que hace la llamada de lectura/escritura) se encaminan a la base de datos por defecto (en este caso la base de datos de Appa):

# settings.py: 
DATABASES['default'] = DATABASES['appA'] 
DATABASE_ROUTERS = ['appA.db.DBRouter', 'appB.db.DBRouter', 'appC.db.DBRouter'] 

# appA/dbrouterA.py (appB, appC routers are identical this, replacing 'appA' with 'appB', etc.) 
class DBRouter(object): 
    def db_for_read(self, model, **hints): 
     if model._meta.app_label == 'appA': 
      return 'appA' 
     if model._meta.app_label == 'auth': 
      return 'appA' 
     return None 

    def db_for_write(self, model, **hints): 
     if model._meta.app_label == 'appA': 
      return 'appA' 
     if model._meta.app_label == 'auth': 
      return 'appA' 
     return None 

2)Suponiendo que funcione el enrutamiento, si un usuario inicia sesión en appA, no quiero que inicie sesión en la aplicaciónB. He visto a muchas personas publicar la pregunta inversa (quieren que sus aplicaciones compartan las credenciales de los usuarios), pero ¿alguien ha utilizado con éxito la autenticación de usuarios de Django en varias aplicaciones independientes en el mismo proyecto? Si es así, ¿cómo hiciste esto?

3) Recibo el siguiente error de mi código taggit, pero no he podido averiguar cómo pasar el parámetro "related_name" a taggit. Estoy usando la aplicación básica de Taggit - no nada de subclases:

# appA/models.py 
tags = TaggableManager(blank=True) 

# appB/models.py 
tags = TaggableManager(blank=True) 

error:

appA.userprofile: Accessor for m2m field 'tagged_items' clashes with related m2m field 'TaggedItem.userprofile_set'. Add a related_name argument to the definition for 'tagged_items'. 
appB.userprofile: Accessor for m2m field 'tagged_items' clashes with related m2m field 'TaggedItem.userprofile_set'. Add a related_name argument to the definition for 'tagged_items'. 

4) estoy empezando a tener la sensación de que la combinación de todas estas aplicaciones es una resbaladiza cuesta abajo; que más adelante en la línea podría tener problemas con sorl-thumbnail o comentarios que aún no han aparecido. ¿Alguien ha combinado con éxito aplicaciones en un solo proyecto? ¿O estoy tratando de hacer algo que Django no apoya fundamentalmente?

¡Gracias de antemano por la ayuda!

+0

¿Por qué quieres combinarlos? Me parece que realmente quieres mantenerlos separados, incluso la tabla de autenticación no se comparte. De todos modos, al menos tendrías que construir un nuevo back-end de autenticación que use 'using()' en la llamada get, así como un manejador de sesión que sepa en qué aplicación estás conectado ... Mi instinto me dice que esto es territorio muy inexplorado. ¡Buena suerte! –

+0

Mi objetivo final es consolidar las aplicaciones (es decir, 1 proyecto de Django con 1 aplicación; actualmente, muchas de las aplicaciones comparten un código común). Pero como primer paso, pensé que los combinaría a todos en 1 proyecto; sin embargo, esto es mucho más difícil de lo que pensaba. Gracias por la info! – jewelia

+0

hmm interesante. ¿Quizás podría comenzar a abordar ese proyecto tratando con la autenticación en la base de datos predeterminada como lo haría en el producto combinado final? ¡Tu código no debería cambiar de la etapa intermedia (5 aplicaciones) a la final (1 aplicación) cuando combinas bases de datos si creas una interfaz de autenticación que manejaría inicios de sesión separados para diferentes secciones del sitio! También un consejo: probablemente obtendrías más ayuda si separas tu pregunta de autenticación de tu pregunta sobre el taggit. –

Respuesta

1

La arquitectura de Django está diseñada para girar en torno a un proyecto de Django y varias aplicaciones de Django. El proyecto en sí no es más que su configuración y el módulo principal de configuración de URL, mientras que las aplicaciones son paquetes simples que siguen algunas convenciones de archivos.

Ahora, las aplicaciones en sí mismas nunca se acoplan a un proyecto en particular (aunque se pueden acoplar a otras aplicaciones haciendo referencia a ellas). La idea es permitirle conservar la libertad de diseñar cómo se estructuran las fuentes de su proyecto y un enfoque común para la mayoría de los proyectos de Django es distribuir las aplicaciones de Django en el paquete de nivel superior del proyecto, como la mayoría de las aplicaciones de Python.Este enfoque hace que sea conveniente obtener una vista holística de todas las características que proporciona un proyecto (cuando aplica etiquetas de aplicación significativas), crear espacios de nombres y proporciona a los desarrolladores una ruta de acceso conveniente y organizada a fuentes de proyectos particulares.

Esto funciona muy bien tanto para proyectos de gran tamaño como cuando desea colocar y fusionar varios proyectos diferentes que reutilizan diseños y enfoques similares. Si bien esto solo afectará a la estructura de su proyecto, la elección de si tendrá o no una configuración para un único proyecto de Django o varios proyectos de Django para su conjunto fijo de aplicaciones de Django tiene algunas ramificaciones importantes.

Cuando se crea un proyecto de Django, su básicamente de conectar aplicaciones Django en la instrumentación del marco y la exposición de comportamiento de la aplicación, tal como la entendemos en aplicaciones Web, mediante la configuración e incluyendo los patrones de asignación de direcciones URL y las vistas desde sus aplicaciones Django.

El punto es que puede reorganizar las fuentes de cualquier manera que funcione para usted. Sus paquetes pueden organizarse como proj.appA, proj.appB, etc. o proj.common1, proj.common2, proj.projA.app1, proj.projA.app2, proj.projB.app1, es realmente decisión suya.

Lo que debe saber es que no necesita una sola configuración y módulo URL y recurrir al enrutamiento de bases de datos y administrar conexiones de bases de datos, también puede tener una configuración y módulo URL para cada proyecto, que hacen referencia a diferentes aplicaciones y exponer un comportamiento diferente. Con la configuración de la base de datos del proyecto, el código que ya está reutilizando y manteniendo los datos y el estado de la base de datos distintos para cada proyecto al mismo tiempo.

+0

Perdóneme por ser denso, pero realmente no puedo ver cómo responde esto a las preguntas del OP ... Podría aclaras eso un poco? –

Cuestiones relacionadas