[pyar] Django y puerto serie.

[Bruno Geninatti]

Gracias Nahuel.

 Creo que entiendo lo que planteas. Mantener a mi recurso en un thread
separado de la aplicación.
 Como me decís, la instancia va a poder acceder al ORM, te consulto: ¿Los
modelos podrán también acceder a esta instancia?.
Una de las operaciones que tengo que hacer es, por ejemplo, realizar un
request que grabe un programa en mi base de datos y a la vez lo grabe via
puerto serie en un micro del hardware, y asegurar la integridad en ambos
lados (base de datos y micro). Sólo así dar el OK al request.
 A la inversa, la instancia que se comunica con el hardware reporta a la
aplicación web información sobre la ejecución del programa que, en algunos
casos, es guardada en la base de datos mediante el ORM, y en otras sólo
reportada al usuario en la respuesta del request.

Muchas gracias

El 30 de marzo de 2015, 13:27, Nahuel Defosse <nahuel.defosse en gmail.com>
escribió:

> Hola Bruno,
>
> Quizás una forma relativamente sencilla de propagar las settings y dividir
> responsabilidades es crear un management command.
>
> Éste puede acceder al ORM, tiene todas las settings, pero es un proceso
> diferente al que va a servir tu aplicación y no bloquea (o momentáneamente
> un hilo).
>
> He tenido problemas con los procesos de larga duración con el crecimiento
> del heap y tenerlo como hilo o co-rutina/green thread/etc. en tu loop con
> tu wsgi puede ser contraproducente.
>
> Saludos!
>
>
>
>
> El 30/3/2015, a las 12:58 p.m., Bruno Geninatti <brunogeninatti en gmail.com>
> escribió:
>
> Buenos días querida comunidad. Trataré de ser lo mas sintético posible.
>
>  Desde hace un tiempo estoy trabajando en algunos proyectos que implican
> la comunicación de una base de datos y servidor web con algún hardware via
> puerto serie.
>
>  Estaba utilizando tornado para el webserver, pero desde hace poco me puse
> a probar utilizar django.
>
>  El webserver deberá inicializar una instancia que contenga toda la lógica
> de comunicación con el hardware específico. Cuando utilizaba tornado, esto
> lo hacía en la aplicación. Por ejemplo:
>
> class Application(web.Application):
>     def __init__(self):
>         handlers = [
>                 (r"/?", HomeHandler),
>         ]
>         settings = dict(
>             template_path=os.path.join(os.path.dirname(__file__), "templates"),
>             static_path=os.path.join(os.path.dirname(__file__), "static"),
>         )
>         self.maquina = Maquina()
>
>         web.Application.__init__(self, handlers, **settings)
>
>
> De esta forma podía comunicarme con "maquina" en la instancia de cada
> handler mediante "self.application.maquina".
> No tengo en claro como podría hacer algo similar en Django.
> Debería inicializar la instancia en settings, para que todas las
> aplicaciones puedan acceder a ella?
> Debería inicializar la instancia en una aplicación específica y que las
> demás aplicaciones accedan a ella o ejecuten funciones por medio de signals?
>
> Creo que el problema se resume a utilizar recursos externos en django, si
> no me equivoco.
> Muchas gracias y saludos
>
> Bruno
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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/20150330/6c270292/attachment.html>