[pyar] Django como servicio web

[Charly Román]

Justamente para eso te puede servir los sites. Como yo lo uso es un
settings.py (con su SITE_ID y su base de datos individual) y quedan
separados totalmente.

Saludos!


El 23 de junio de 2014, 14:17, Manuel Kaufmann <humitos en gmail.com> escribió:

> Claro, con respecto a "la misma instancia" y "múltiples db por
> diferencias de Fields" es porque quiero tener un código genérico que
> todos los sitios van a usar, pero además también quiero ser flexible
> bajo ciertos límites para hacer que esos sitios sean customizable.
>
> Para eso, lo que quiero usar es django-easyconfig[1] que, mediante un
> objeto Config te permite decir qué View, Model y Form utilizar, por
> ejemplo. Entonces la idea sería algo así como "hacer una Django
> Application que se pueda instalar muchas veces en un Django Project y
> sea customizable por ese objeto Config".
>
> Lo primero que había pensado era usar Site y no me convenció porque
> quiero aislación de datos entre los sitios y lo otro era múltiples DBs
> que se seleccione automáticamente la correcta basándose en el Request
> pero eso agrega algunas complicaciones (como ese tema de hilos -que no
> tengo claro) y otros.
>
> Ahora, habiendo leído un poco lo que comentan ustedes, me parece que
> una aproximación interesante sería mezclar:
>
>  * django-easyconfig (un objeto Config por cada sitio -cada sitio
> sería una mini-django-app con View, Model y Forms específicos para
> ella)
>  * diferentes settings.py (para algunas pequeñas cosas que
> django-easyconfig no cubra) con su DB particular
>  * múltiples instancias de uwsgi con diferentes settings
>  * un server nginx con múltiples hosts apuntando a los diferentes uwsgi
>
> ¿Cómo lo ven? ¿Es más claro ahora el problema que quiero resolver?
>
> Entiendo que esto me permitiría hacer que todos los sitios utilicen el
> mismo código de la App genérica (cosa de que si hay un bug lo arreglo
> en esa y todos heredan el FIX) y además, poder hacer customizaciones
> por sitio usando el objeto Config de esa app específica.
>
> Por otro lado, ¿se podría llegar a algo similar a esto pero sin
> múltiples instancias de uwsgi? ¿cuál es el problema de tener muchas
> instancias uwsgi además del consumo de memoria?
>
> [1] https://bitbucket.org/petersanchez/django-easyconfig/
>
> 2014-06-23 14:28 GMT-03:00 Ariel Camino <arielcamino en gmail.com>:
> > 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
> > _______________________________________________
> > 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
>
>
>
> --
> Kaufmann Manuel
> -- http://elblogdehumitos.com.ar
> _______________________________________________
> 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
>



-- 
Charly Román
Software Developer
http://croman.mx
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140623/a1722d9e/attachment-0001.html>