GeneXus Freeze Version 2.0

Una muy buena característica de GeneXus es la que permite congelar versiones para tener una foto de como estaba la KB en un momento dado, que sirve por ejemplo para guardar la versión liberada a los clientes.

El problema que tienen las versiones congeladas, es que cuando uno quiere utilizarlas, el proceso de reconstruir el ambiente demora muchísimo, sobre todo en KB grandes.

Lo que me gustaría  seria poder guardar ademas de los objetos read-only, una copia de los archivos de espcificación, los fuentes generados y una forma fácil de cargar los datos que tiene mi aplicación.

Para lograr esto, seria bueno que el dialogo de Freeze  hiciera algunas preguntas

* salvar programas y información de especificación?
Salvaría el Target Path y el directorio GXSPC00xx, al nuevo directorio de la version congelada.

* save data ?
Esta opción, generaria una copia de los datos de la base de datos.
Mi idea seria generar un archivo XML por cada tabla de la base de datos, que tenga

<Tabla>
    <Tabla_registro>
          <Atributo1>XXX</Atributo1>
          <Atributo2>YYY</Atributo2>
   </Tabla_registro>
</Tabla>



También se generaría un procedure para cada tabla, que genere lea el archivo y lo grabe en la base de datos.
Y un programa que llame a todos los anteriores, en orden para no tener problemas con la integridad referencial.

Esto también seria bueno poder subirlo a GXServer.

Supongamos que alguien crea una versión derivada de esa versión congelada, seria mucho mas fácil y rápido levantar desde la versión congelada y luego aplicarle los cambios de la nueva versión derivada de ella.

Se me ocurre que se podría bajar la versión congelada, con los programas, hacer un Create database, cargo los datos y luego aplico todos los cambios que se hicieron en la nueva versión. La opcion de salvar y cargar datos, puede usarse en escenarios de pruebas y migraciones, donde es importante poder armar una base de datos con datos coherentes relativamente rápido.

UPDATE: Otra cosa que debería poder salvarse, porque demora muchísimo en regenerarse es el indice del Full Text Search de GeneXus.

Comentarios

  1. Pero con el nuevo manejo de BRANCH, no es posible hacer esto ? al menos del punto de vista de la KB

    Si entiendo que deberia tambien congelarse la Base de Datos + Datos para que quede reconstruible todo

    ResponderEliminar
  2. Esteban:
    Al congelar la versión, se deja una foto de como estan los objetos en la KB. Con eso se puede recrear facilmente la base de datos y los programas pero dicha tarea demora mucho. Pues se necesita un create database, copiar los datos (que tenes que haber salvado de alguna forma) y un build all. Esto puede demorar mas que muchas horas.

    Mi propuesta es lograr bajar estos tiempos, para que sea mas facil recuperar el estado de la KB, sin tener que recurrir a backups por fuera de GeneXus.

    ResponderEliminar
  3. Enrique, está buena la idea.
    Ahora, querés guardar las tablas en XML por algo en particular?
    Porque la mayoría de los dbms tienen su propio "dump" para generarte las sentencias SQL que reconstruyan las tablas. Claro que ahí tendría GeneXus que llamar algun command-line del dbms, pero supongo que no sería demasiado complejo integrarlo, y ahí te ahorrás la implementación del pasaje de tablas->xml->tablas.

    Pensás guardar todos los datos también? Eso no podría resultar demasiado pesado si va a un XML?

    ResponderEliminar
  4. Sebastian:
    La idea de hacerlo con XML es para no depender de herramientas de los DBMS, de forma que sirva para pasar datos de un manejador a otro, por ejemplo de SQL Server a Oracle, de forma facil.
    El formato de los dumps (BCP en SQL Server, SQLLoader en oracle, etc) son muy dependiente de la base de datos y de la version de los mismos. Prefiero tener un formato facil de entender y de manejar, para empezar.

    El salvado de las tablas, deberia ser opcional, teniendo una lista de tablas que no me interesa guardar (logs, acumulados, etc). Tambien se podria limitar la cantidad de registros que se quiere salvar por tabla, pero esas cosas hacen mas complejo el desarrollo y me gustaria empezar con algo sencillo.

    ResponderEliminar
  5. Bien, me queda claro entonces el por qué del XML. De todas maneras creo que yo separaría las estructuras de los datos.
    Estos últimos capaz los pondría en un csv (uno por tabla), de forma que te queda lo suficientemente "genérico" como para levantarlo para cualquier dbms (incluso con un proc como planteás), y siempre es mas liviano que el XML si tuvieras un buen volumen.

    Le veo tremenda utilidad, que siempre es una masa tener que armar las versiones anteriores tal cual las necesitamos.
    Saludos!

    ResponderEliminar
    Respuestas
    1. El usar CSV si bien ahorra espacio, y es mas rapido para procesar, es problematico si los campos cambian de posicion. Con un XML ese problema se elimina.

      Si pensas que esto es para reconstruir versiones viejas, creo que puede ser mejor guardarlo en un formato mas perdurable. De cualquier forma, el formato de los datos, podria ser opcional (XML, json, CSV, BACKUP o export nativo) , siempre que se tengan programas que sepan interpretarlos correctamente.

      Lo fundamental, es poder reconstuir todo como estaba en el momento que se congelo, de forma de poder volver a tener las mismas estructuras y los mismos datos.

      Eliminar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

El Sordo

StackOverflow Documentation

Codigo simple