La reorganización de la base de datos (RGZDB) es, básicamente, el proceso resultante de analizar dos estructuras de base de datos (la actual y la diseñada) para determinar la mejor forma de convertir una en la otra con la menor pérdida de información.
La capacidad de GeneXus de realizar automáticamente la RGZDB es uno de los diferenciadores mayores de nuestro producto. Sin ella, el modelo de desarrollo incremental propuesto por GeneXus sería prácticamente imposible de implementar.
Con el aporte de ideas y la descripción de situaciones y su posible solución, obtenidas de nuestros clientes, beta testers y de nosotros mismos, la versión Olimar de GeneXus ha "revitalizado" la RGZDB en diferentes aspectos:
Impact Analysis Report (IAR)
El IAR es el informe que resulta de comparar la estructura actual y diseñada de la base de datos. Muestra qué le ha ocurrido a cada tabla y explica cuál es el proceso de conversión que le aplica. Si bien es un informe de mucha importancia, adquiere una relevancia especial en proyectos donde se involucra a muchos desarrolladores y se consolidan los cambios de varios en una única Knowledge Base (KB): es el medio que tiene GeneXus para comunicarse tanto con quien "evalúa" la calidad de la estructura de datos como con quien tiene que planificar y ejecutar la reorganización.
Modificaciones del IAR en la versión Olimar de GeneXus:
· El más visible es el cambio de aspecto. Se modificaron íconos, colores, etc. como forma de hacerlo más legible.
· Se agregó la información relacionada con la integridad referencial que nos permite saber por qué existen los índices que GeneXus define automáticamente, y detectar posibles diferencias entre lo modelado y lo que se quería modelar, o errores en el modelo.
· Se analizan y muestran los cambios en las tablas externas así como en las declaradas en el server (y se ha solicitado no reorganizarlas) permitiendo tanto informar los cambios que tienen que hacerse a estas tablas no reorganizadas por GeneXus como detectar cambios que se realizaron sin intención.
· Las propiedades más relevantes de los atributos son mostradas claramente. Esto incluye el tipo de datos, posibilidad de ser nulo, autonumeración, etc.
· Se muestran los cambios ocurridos aún cuando éstos no impliquen reorganización. Esto permite ver modificaciones en tablas externas o declaradas "en el server" y decidir si se desea o no actualizar el modelo.
· Se implementaron más avisos o errores que ayudan al desarrollador a detectar y corregir posibles situaciones de error con anticipación.
· Los errores que pudieran detectarse impiden que la reorganización se genere y ejecute.
Más casos de conversión de datos
En versiones anteriores se daban situaciones en las que el desarrollador esperaba que ocurriera cierta conversión basada en los cambios que se habían realizado pero estos no se producían. GeneXus no sabía cómo realizarlos. En muchos casos esto era "inexplicable" para el desarrollador.
Las mejoras en la versión Olimar seguramente reducen a un mínimo estas desilusiones al haber incorporado muchas de las sugerencias de reorganización recibidas haciéndola más "natural" o predecible:
· Las tablas que ya no existen en el modelo, ahora también son eliminadas de la base de datos.
· Al cambiar la llave primaria de una tabla se mantienen sus datos. Este, creo, era uno de los puntos más difíciles de entender principalmente para los nuevos usuarios de nuestro producto. La versión Olimar de GeneXus permite que la llave primaria de una tabla cambie y convertir los datos a la nueva estructura.
· La sustitución de un atributo por un subtipo de este o viceversa mantiene los datos, inicializando uno con el otro. Al sustituir, por ejemplo, el atributo CustId por el atributo CustIdInvoice los valores de CustId se asignan a CustIdInvoice automáticamente. Esto resulta en una mayor facilidad para implementar subtipos en la medida que la aplicación va cambiando con los requerimientos.
· La definición de subtipos sobre atributos ya existentes migra los datos. Este es una reorganización relativamente común entre nuestros usuarios a medida que los modelos de datos evolucionan. Por ejemplo, se define inicialmente una transacción de Customers pero, con el tiempo, resulta necesario unificar a todas las entidades que tienen alguna relación con la aplicación. Se define entonces una transacción de Companies y, los atributos de la transacción de Customers pasan a ser subtipos de los de Companies. La versión Olimar es capaz de poblar la tabla de Companies a partir de la tabla de Customers ya existente.
Un aspecto interesante de esta reorganización es que podrían existir varias tablas "origen" (Customer) para una misma tabla "destino" (Companies).
· Propiedad "Initial value" para atributos. El dar un valor inicial a un atributo permite que GeneXus se lo asigne cuando el atributo pasa a formar parte de una tabla ya existente. Esto elimina la necesidad de programar un Procedure que lo haga.
Controles para anticipar fallas
En la RGZDB, siempre que es posible, GeneXus propone soluciones para situaciones que podrían provocar un error cuando existe una alternativa razonable y muestra un aviso indicando la situación. Por ejemplo, si un atributo no permite nulos pero existe la posibilidad de que los tenga, GeneXus indica que esto puede ocurrir y cómo lo resolverá.
En situaciones donde no es posible encontrar una alternativa razonable GeneXus muestra un error que debe ser resuelto para poder continuar.
Los mensajes de aviso y error han sido incrementados de forma evitar resultados no deseados o errores que en versiones anteriores no se detectaban con suficiente anticipación.
Más importante aún es la implementación de controles que se realizan en tiempo de ejecución de los programas de reorganización. Para cada caso en que la única forma de saber si ha de ocurrir un error, es conocer los datos que existen en las tablas, la versión Olimar de GeneXus es capaz de escribir el código necesario para identificar el error y detener la ejecución de la reorganización en forma temprana.
La definición de un índice único, por ejemplo, sobre una tabla existente podría falla si existen duplicados en los datos ya cargados. GeneXus genera código que controla, en tiempo de ejecución, la duplicación de llaves únicas cancelando la reorganización antes que esta ejecute.
Presente y futuro
Sé que hemos avanzado en forma importante en uno de los aspectos diferenciadores de nuestro producto ayudando a nuestros clientes a focalizarse cada vez más en los aspectos del negocio y menos en los técnicos. Afortunadamente, por el gusto con el que las encaramos, tenemos aún muchas cosas por hacer en esta área. Con el aporte de nuestros clientes podremos agregar algunas a la lista. Siéntanse libres de hacernos llegar sus sugerencias (y soluciones, en lo posible). A ellas nos dedicaremos en las próximas versiones.