[pyar] Django como servicio web

[Pedro Jose Pezzarini]

Lo que se me ocurre es que tengas una config blanca y sin dbs, y las
configs de cada sitio en forma individual:
settings.py, settings-site1.py, settings-site2.py

Y un url que sirva como "enrutador":
urls.py, urls-site1.py, urls-site2.py

Y cuando recibís la solicitud filtrada desde urls.py, sobreescribis la
config blanca (settings.py) con la del sitio que querés, y cargás las
urls-site dependiendo de la solicitud.

No se si es muy optimo, y aclaro que nunca hice algo así.

Saludos y por favor comenta la implementación que te resolvió el problema,
que esta muy copado.
Exitos!.




El 23 de junio de 2014, 14:35, Ariel Camino <arielcamino en gmail.com>
escribió:

> El 23/06/14 14:28, Ariel Camino escribió:
> > El 23/06/14 14:02, Manuel Kaufmann escribió:
> >> Hola,
> >>
> >> Estoy migrando un Proyecto Django para convertirlo en una Aplicación
> >> Django con el fin de alojar muchos sitios en una sola instancia de
> >> Django (en pocas palabras). Para eso, el servidor va a hostear muchos
> >> nombres de dominios y, dependiendo de eso, se debería mostrar X o Y
> >> (datos, templates, demáses)
> >>
> >> Esto quiere decir que todos los sitios "instalados" en mi instancia de
> >> Django van a tener las mismas tablas de datos -pero no deben compartir
> >> información- e incluso, puede ser que haya algunas pequeñas
> >> modificaciones en esas tablas. Por ejemplo, un sitio puede ser pago y
> >> tener un BooleanField llamado "ya_pago" en la tabla UserProfile y los
> >> otros sitios no tener ese Field.
> >>
> >> Entonces, estuve buscando información y caí en maejar estas dos
> opciones:
> >>
> >>  1) Usar Sites Framework
> >>
> >> Un perno. Tengo que cambiar toda la implementación del sitio para
> >> filtrar por Site y agregar un Field a cada uno de mis modelos. Además,
> >> tampoco me queda la información separada ya que usaría la misma DB y
> >> los datos estarían todos mezclados...
> >>
> >> No me gustó mucho esa aproximación...
> >>
> >>  2) Usar Múltiples Databases
> >>
> >> Hasta ahora, no encontré una forma de decir: "si viene de
> >> foo.example.com, utilizar la DB 'foo' y si viene de bar.example.com
> >> utilizar la DB 'bar' " :(
> >>
> >> Lo que encontré es una aproximación a lo que quiero: usas SCHEMAS;
> >> pero casi que estoy en lo mismo que arriba: una sola DB con todos los
> >> datos mezclados pero asignados a un SCHEMA.
> >>
> >> https://github.com/bernardopires/django-tenant-schemas/
> >>
> >> Por otro lado, encontré este:
> >>
> >> https://github.com/mik3y/django-db-multitenant
> >>
> >> que implementa "muy bien" eso pero solo funciona en MySQL y yo lo
> >> necesito en PostgreSQL. Estoy viendo qué tan complicado puede ser
> >> modificarlo para que se la banque. Igualmente, si lo hago, tampoco
> >> podría medir los riesgos que estaría corriendo ya que hay un tema con
> >> los threads de Django en este approach :S
> >>
> >> ¿Sugerencias? ¿Opiniones? ¿Etcéteras?
> >>
> >> ¿Han tenido este problema? ¿Cómo lo resolvieron?
> >>
> >> Gracias. Muchas gracias, y hasta luego.
> >>
> >> === Lo que estuve leyendo ===
> >>
> >>  * http://en.wikipedia.org/wiki/Multitenancy
> >>
> >>  * https://docs.djangoproject.com/en/dev/ref/contrib/sites/
> >>  *
> https://docs.djangoproject.com/en/dev/ref/contrib/sites/#the-currentsitemanager
> >>
> >>  * https://docs.djangoproject.com/en/dev/topics/db/multi-db/
> >>
> >>  *
> http://stackoverflow.com/questions/16721051/multi-tenant-django-applications-altering-database-connection-per-request
> >>  *
> http://stackoverflow.com/questions/7970872/how-to-use-a-different-database-per-application-instance-in-django
> >>
> >>  * https://github.com/mik3y/django-db-multitenant (MySQL-only (this
> >> should be fixed eventually).)
> >>
> >>  * https://github.com/bernardopires/django-tenant-schemas/
> >>    * http://www.postgresql.org/docs/9.1/static/ddl-schemas.html
> >>
> >
> > Hola, para ver si te entendí bien, necesito entender cual es el problema.
> >
> > 1- No queres tener multiples dbs: Primero entendí esto ("en mi instancia
> > de Django van a tener las mismas tablas de datos"), pero después decís
> > que no te convence Sites, porque vas a tener los datos en las mismas
> > tablas, por lo que entiendo que entonces esto no es un problema.
> >
> > 2- No queres tener distintas instancias de django que hagan lo mismo:
> > Esto se puede encarar de varias formas, pero si tenes diferencias en el
> > código (por ejemplo un sitio puede tener un BooleanField y otro no)
> > claramente no puede ser la misma instancia de django, o al menos no
> > "toda" la misma instancia.
> >
> > Si mi interpretación anterior es correcta, creo que lo que necesitás
> > hacer son apps enchufables que puedas agregar (por ejemplo con pip) a tu
> > proyecto de django, luego si necesitás por ejemplo modificar un modelo
> > puntual, podes seguir usando todas las cosas de tu app enchufable, menos
> > x modelo que sobreescribis en el proyecto.
> >
> > Esa es la forma más sencilla que se me ocurre (así funcionan todas las
> > apps/plugins de django que están dando vueltas por ahí).
> >
> > Igual en este caso las "instancias" de django serían distintas, solo
> > compartirían partes de código en común (views, models, templates, etc).
> >
> > Saludos!
> > --
> > Ariel
> >
>
> Otra forma de encararlo, deployas 1 instancia sola de django, creas un
> settings base y un settings "de instancia", por ejemplo:
>
> base.py -> todos los settings
> misitio1.com.py -> import base.py y config de la base de datos
> misitio2.com.py -> import base.py y config de otra base de datos
>
> luego creas dos wsgi.py, uno que importa misitio1.com.py, y el otro
> (wsgi2.py) que importa misitio2.com.py, y configuras
> apache/gunicorn/lo_que_sea con ambas instancias
>
> Nótese que en misitio1.com.py podes sobreescribir cualquier setting, por
> ejemplo que en vez de cargar tu app con modelos free, cargue tu app con
> modelos pagos.
>
> Igual es el mismo caso que el anterior, tenes código en común, pero las
> "instancias" de django son distintas.
>
> Suerte!
> --
> Ariel
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140623/038c9ef4/attachment.html>