Ya se que se pueden utilizar metodologías ágiles independientemente de las herramientas que utilices, “Agile” es un método iterativo de gestionar un equipo que realiza tareas abstractas para crear un producto concreto, independientemente de que uses C, Ada, Logo o Smalltalk.
… Vale !, … expondré un caso:
Uno de los productos de Peoplecall es lo que llamamos el ADSMY ( … lo que significan los acrónimos es una muy larga historia) pero quedaos con que es un sistema para que los Callshops vean su saldo, manejen sus llamadas, configuren el servicio, etc.
Pues bien, esta aplicación utiliza una base de datos relacional (postgres) y utilizamos Hibernate como ORM.
Tenemos además el Hudson como servidor de Integración contínua, de modo que cuando alguien realiza un commit en el trunk (usamos subversion) el hudson compila el proyecto (usamos maven) y lo despliega en el servidor de pruebas (usamos Glassfish) que está accesible en el site de preview.
Si todo va bien, ejecutando una tarea del hudson, el software se despliega en producción.
Todo muy bonito.
Pero el principal problema lo tenemos en la base de datos, es el “gran singleton”, evolucionar el esquema automáticamente resulta muy complicado, y aunque en el caso del postgres, el DDL es transaccional, hacer evolucionar el esquema para adelante y detrás es complicado, y el ORM no ayuda.
Puede darse el caso de que refactorizando un par de objetos, en el esquema resultante se añadan varias tablas y se modifiquen demasiadas reglas de consistencia como para hacer una transición sencilla.
El caso es que ahora vamos a modificar nuestro ADSMY, nos hemos planteado cambiar de una base relacional a una NoSQL, en concreto a la Berkeley DB JE.
De esta forma, los datos pertenecen a la aplicación, no hay esquema, no hay servidor, es como si los objetos estuviesen persistidos en un hash, es una base de datos escrita para programadores, no para DBAs.
Actualizar un objeto es tan simple como:
newCustomerPK.put(new NewCustomer(oldCustomerPK.get(customerId)));
Aunque en el caso de la Berkeley tiene las “Mutations” que valen para esto.
Los inicios del desarrollo son muy alentadores, el modelo de datos sale muchísimo mas simple y mas potente. Puesto que no hay ORM por medio, si un objeto tiene dentro una lista, se persiste y punto, no necesita una tabla auxiliar con un join y una clave.
Y si simplificamos el modelo de datos y simplificamos el mecanismo de evolución, es más sencillo meter dentro de la nueva versión código para evolucionar los datos de la versión anterior, y todo lo que ayude a evolucionar … es mas Agile .. ¿no?
Herme, yo no tengo ni idea de como funciona la Berkeley, pero había leído en algún sitio que la gran pega es que es complicado realizar consultas ad-hoc... ¿es así?
Publicado por: Esteban27 | 24/01/11 en 0:32
Y has leido bien ... es tan complicado como que no se puede !!!, no se puede conectar desde fuera y ejecutar un query.
Las consultas deben hacerse en código y en el mismo proceso que el resto de la aplicación.
Para ese tipo de consultas hemos barajado varias opciones:
1) Copia replicada en R/O en otra maquina y ejecutables ad-hoc que exportan datos desnormalizados (CSV, INSERTS, etc) para utilizar herramientas de reporting.
2) Programa de linea de comandos que se ejecuta con el appclient de Glassfish de modo que tiene acceso al entorno completo de J2EE y puede acceder a la red de objetos en marcha. Además podria admitir trozos de código en Javascript (Rhino).
3) Servlet interactivo tipo query/response pero en javascript, con una biblioteca de funciones para que sea comodo realizar consultas.
Por ahora la 2 es la que va ganando.
La realidad es que el NoSQL es otro mundo, pero si lo que queremos es mantener la red de objetos persistida, no tiene sentido realizar consultas a otro sitio que no sea esa misma red de objetos.
Esteban .. a ver que sale !!
Publicado por: Herme García | 24/01/11 en 1:14