Entre los dias 1 y 12 de Agosto hemos estado probando nuevas ideas y tecnologias para desarrollar un pequeño ERP. En este documento se resumen las principales conclusiones que hemos obtenido a partir de esta experiencia.

Postgresql y Python

Para la parte del servidor hemos probado postgresql sin ninguna capa intermedia de conversion SQL a objetos. La idea principal es poner toda la logica de negocio que podamos en triggers de Postgresql.

Los triggers se escriben en Python y las ventajas de esta aproximacion son las siguientes:

• Los triggers se ejecutan bajo un entorno transaccional por lo que si hay un error en la logica de negocio y falla la transaccion todo vuelve al estado anterior y la consistencia de datos se mejora enormemente.
• Se pueden utilizar todas las facilidades de Python para la reutilizacion de codigo. Principalmente la herencia de sus clases y la utilizacion de toda la libreria de codigo de Python.
• Normalmente el codigo de los triggers en postgresql sera del tipo: import modulodenegocio; modulodenegocio.funcion() . Es decir, el codigo esta en ficheros de texto normales y corrientes y cambiando el pythonpath accedemos a ellos de forma transparente. Las ventajas son enormes como por ejemplo poder usar un sistema de control de versiones directamente y sin ningun problema.

Conforme hemos ido desarrollando siguiendo esta idea nos hemos dado cuenta de posibles refactorizaciones y abstracciones de tal forma que al final el codigo de los triggers es practicamente generico y se puede generar automaticamente mediante un script. Esto es el codigo que va dentro de Postgresql, evidentemente la logica de negocio, que va en archivos Python, no se puede automatizar.

Con funciones de recarga de modulos hemos conseguido que no sea necesario reiniciar el motor de base de datos cada vez que realizamos cambios en la logica de negocio, algo extremadamente util en ambientes de produccion.

Todas estas ideas se pueden ver en http://projects.sicem.biz/microgest/browser/

Las cosas que hemos probado han funcionado bien en Postgresql 7.X (Erny, debian) y en Postgresql 8.X (Loren, fedora). En general la experiencia con Postgresql ha sido muy satisfactoria.

Rekall

Para la parte del cliente se ha escogido Rekall porque es un entorno con buenas ideas y que permite un desarrollo agil.

La version que hemos utilizado de Rekall ha sido la 2.3.4. A Erny (Debian) nunca le dio problemas pero a Loren (Fedora) si. Al princpio la compilo con la libreria Qt que traia Fedora y aparentemente algunos ComboBoxes en Rekall no funcionaban correctamente. Se descargo la libreria Qt en fuentes, se compilo y el problema desaparecio. Sin embargo, y debido probablemente a que esta version de la libreria Qt fue compilada sin soporte multithread, los cuelgues en Rekall se produjeron con relativa frecuencia.

Tras instalar Rekall nos costo un poco hacernos con el diseño de formularios pero una vez entendidos algunos conceptos nos gusto bastante y conseguimos algunos resultados buenos. Tiene cosas por pulir como que guarde automaticamente los cambios cuando se conmuta entre modo diseño y modo ejecucion. Una cosa realmente buena de Rekall es que todo se puede almacenar en archivos XML por lo que pudimos usar un sistema de control de versiones y la integracion de los cambios que hacia cada uno era practicamente automatica.

Sin embargo en la parte de diseño de informes los resultados no fueron tan buenos ya que se nota demasiada falta de madurez en este modulo. Se rompia constantemente, las etiquetas no se pintaban adecuadamente y en general, era bastante dificil conseguir un informe. Esto nos hizo pensar que por ahora probablemente sea mas adecuado utilizar motores de informes externos como Agatha Reports.

Por tanto, en general, la experiencia con Rekall no ha sido tan satisfactoria como con Postgresql principalmente debido a que hay una gran diferencia de edad entre ambos proyectos, y por tanto de madurez.