[pyar] Hola Lista!

[Carlos Matías]

Nicolás,

apoyo a los que mencionaron usar un ORM.

Ya que vas a tener que acceder a una BD de manera remota, te sugiero uses
algún framework. Como Django o Flask. Yo en particular uso Django y te lo
recomiendo mucho. Además de proveer un ORM magnífico, te ayudará con muchas
cuestiones que no podés dejar de tener en cuenta:
 - Gestión de usuarios (autenticación y permisos)
 - Cuestiones de seguridad
 - Facilidad para exponer una API REST (via DRF
<http://www.django-rest-framework.org/>)
 - una gran comunidad de soporte

Entiendo que también te puede servir Flask, de la misma manera.

Con eso, tendrás una aplicación WEB, que se encarga de administrar la DB e
implementar la lógica de negocios que necesites. Por ejemplo, esas
validaciones que mencionaste antes de insertar datos, usar transacciones
para permitir concurrencia, etc.

Luego, el frontend (la interfáz de usario o UI) lo podés hacer de muchas
formas:
 - puede ser una aplicación web que corra en navegadores (en PC y móbiles).
O sea que la estarías haciendo con HTML, CSS y JS. En este caso, podés usar
el mismo servidor web para servir la aplicación web.

 - Podés hacer algo en Qt/GTK/etc para compus de escritorio

 - Kivvy o similar para algo nativo en mobile.

Sea como sea que hagas la UI, esta se va a comunicar con tu servidor web,
via mensajes HTTP (o sea, usando la API REST) y listo.

Ese modelo que te sugiero es muy típico. Le va a resultar familiar a
cualquiera que esté haciendo aplicaciones web (habemus varios en esta
lista).


Abrazo y éxitos en tu proyecto


Carlos Matías
@py_litox <https://twitter.com/py_litox>

2017-02-24 17:43 GMT-03:00 Gustavo Campanelli <gedece en gmail.com>:

>
> 2017-02-24 17:37 GMT-03:00 Andrés Ramírez <andres.ramirez.miori en gmail.com>
> :
>
>> No me refiero a un tema de alta demanda. Si vos tenés una función del tipo
>>
>> def insertar_nuevo_dato (dato):
>>     se_puede_agregar = false
>>     se_puede_agregar = analizar_colisiones (dato)
>>     if se_puede_agregar:
>>         ORM....insertar_dato ()
>>     else:
>>         Hacer algo
>>
>> Si luego de ejecutarse en true la línea
>> se_puede_agregar = analizar_colisiones (dato)
>> Alguien en paralelo hace un insert en la base, cuando tu programa haga la
>> parte del insert lo que tenés en la variable se_puede_agregar ya no es
>> válido
>>
>>
>> El 24 feb. 2017 4:21 PM, "Nicolás Adamo" <nicoadamo en gmail.com> escribió:
>>
>> Buen punto. Lo pensé en su momento y opiné que si llegan varias consultas
>> en simultáneo y el server demora en ejecutarlas, se tiene que crear una
>> cola de trabajos que evite que el sistema colapse.
>> Pero para llegar a eso me falta mucho... :P
>>
>> On Fri, Feb 24, 2017 at 9:09 PM Andrés Ramírez <
>> andres.ramirez.miori en gmail.com> wrote:
>>
>>> Lo van a usar múltiples usuarios al mismo tiempo?. Si los inserts pueden
>>> venir de distintos lados al mismo tiempo también tenés que pensar en
>>> lockear la tabla, porque entre el análisis y el insert puede cambiar
>>>
>>> El 24 feb. 2017 4:05 PM, "Nicolás Adamo" <nicoadamo en gmail.com> escribió:
>>>
>>> On Fri, Feb 24, 2017 at 8:44 PM Rafael E. Ferrero <
>>> rafael.ferrero en gmail.com> wrote:
>>>
>>> El 24 de febrero de 2017, 15:34, Andrés Ramírez <
>>> andres.ramirez.miori en gmail.com> escribió:
>>>
>>> No me queda muy en claro tu necesidad, pero comento un par de cosas que
>>> tal vez te sirvan. Inicialmente siempre he usado MySQL o Postgress, asique
>>> votaría por este último. Con respecto a lo que necesitas hacer antes de
>>> insertar un dato en la base, lo podés hacer programáticamente python (tener
>>> tu función de agregado a la base que antes me consulta por los datos que
>>> querés barrer e inserta sólo si tiene que hacerlo o retorna lo que
>>> necesitas), o a nivel base de datos (usando un trigger del tipo before
>>> insert, o algún store procedure). La última forma tal vez no es recomendada
>>> por que después te puede complicar, temas como cambiar el motor de base de
>>> datos, o recordar que existe código que no está en tu código, etc.
>>> Igualmente también puede ser que no necesites acceder a la base antes de
>>> cada insert y los datos que necesitas ya los tengas en memoria, pero
>>> depende exclusivamente de que estás haciendo.
>>>
>>>
>>> Saludos
>>>
>>> El 24 feb. 2017 2:55 PM, "Nicolás Adamo" <nicoadamo en gmail.com> escribió:
>>>
>>> >>> print("Hola Mundo!")
>>>
>>> [Siguiendo el principio KISS]
>>>
>>> Estimada Lista,
>>>
>>> Los sigo hace tiempo, pero nunca me presenté. Como todo introvertido
>>> hice antes consultas con el maestro Humitos, pero no con la lista :P
>>> Soy Nicolás Adamo, tengo 30 años (por poco tiempo más), soy de Salta,
>>> Ingeniero Civil de la UNSa, y trabajo en una constructora, en el área de
>>> Planificación y Control de Proyectos. Por una oportunidad que se me
>>> presentó, ahora estoy en Egipto trabajando en la ampliación de una
>>> termoeléctrica.
>>>
>>> De todas formas los 3 últimos proyectos en los que participé fueron
>>> acueductos y gasoductos, obras que de forma análoga a las rutas, caminos,
>>> canales y vías férreas, son obras lineales.
>>> En esos proyectos tuve éxito integrando diversos reportes de avance
>>> usando mucho código de VBA (Visual Basic for Applications) adentro de
>>> MS-Excel. Por supuesto que me encanta Python, su sintaxis es bella,
>>> sencilla, multiplataforma y se puede usar en casi cualquier cosa; pero en
>>> el laburo lamentablemente hay lo que hay y me tuve que adaptar a eso.
>>>
>>> Ahora estoy tratando con otros 2 compañeros de hacer una aplicación
>>> robusta, sacando estos algoritmos de MS-Office. Para la interfaz gráfica
>>> inicialmente me agradaba PyQt, pero después alguien en la lista mencionó
>>> Kivy, y me encantó ya que es un desarrollo nuevo, multiplataforma, y
>>> soporta entornos móbiles (Android, iOS, etc).
>>>
>>> Pero con el tema de la base de datos aún ando perdido... Tiene que ser
>>> remota, y para eso sé que existen MariaDB y PostgreeSQL; pero el tema es
>>> que necesito realizar validaciones complejas antes de hacer un insert o
>>> actualizar un registro. Validaciones que implican recorrer los registros de
>>> una tabla *antes* de modificarla, y si hay errores, devolver un objeto con
>>> algunos datos que se encuentran en este barrido previo durante la
>>> validación.
>>>
>>> Alguno pasó por algo parecido? Qué me recomiendan para empezar a mirar?
>>>
>>> Les mando un abrazo y sigan así con la lista que es la mejor, por lejos!
>>>
>>> Saludos,
>>>
>>> Nicolás Adamo
>>>
>>>
>>>
>>> Particularmente yo me inclinaría por usar un ORM como SQLAlchemy...
>>> (personalmente uso Django y su ORM me parece genial) pero por lo que
>>> entendí van por el lado de aplicaciones instalables en cada dispositivo y
>>> no por el lado de las aplicaciones web
>>>
>>> Saludos !!
>>> _______________________________________________
>>> 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
>>>
>>>
>>> Muchas gracias por las sugerencias señores.
>>> Voy a mirar entonces un ORM para evitar el evento before insert.
>>>
>>> A lo que me refiero es que si tengo los siguientes registros:
>>> #Registro |Progresiva Inicio  |Progresiva Fin
>>> 1         |30                 |50
>>> 2         |70                 |100
>>>
>>> (En el ejemplo queda un hueco entre el 50 y el 70).
>>>
>>> Si quiero insertar el registro #3 con inico=40 y fin=70, la validación
>>> que tengo que hacer antes de insertar debe barrer todos los registros y
>>> detectar que con el registro #1 tengo conflicto, porque estoy duplicando el
>>> segmento que va del 40 al 50. Me explico?
>>> Allí debería devolver a la aplicación remota, que intentó cargar ese
>>> registro, información sobre el segmento duplicado.
>>>
>>>
>>> Saludos!
>>>
>>> Nicolás Adamo
>>>
>>> _______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> 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
>
>
> ¿Podes dividir la lógica en dos partes? La primera, del lado del usuario
> se encarga de validaciones senciilas y de enviar los datos. La seguna, del
> lado de la base de datos, realiza los selects necesarios para verificar los
> datos andtes de hacer el insert. Devuelve a la primera parte el resultado
> de la operación para que lo vea el usuariio.
>
> Gedece
>
>
> _______________________________________________
> 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/20170224/40a515b3/attachment-0001.html>