Hola! como va?
Tenemos un problema al migrar en producción 2 proyectos.
Los proyectos se migraron en desarrollo sin problemas. En desarrollo no hay definidas ni perfiles de datos, ni funcionales, ni restricciones, ni usuarios. Solo toba como Administrador.
En producción sin embargo, existe todo eso, perfiles funcionales, restricciones funcionales, perfiles de datos, y usuarios para todos los gustos y colores.
El proceso de migración que se siguió es el siguiente (del machete que usamos para migrar sin problemas de la 1.5 a la 2.1):
Toba 2.1 (backup)
ejecutar en la consola:
- toba proyecto exportar -p mi_proyecto
- toba instancia exportar_local
instalar la nueva versión, desarrollador XXXX, clave postgres = XXXX, clave usuario Toba = XXXX (la misma que antes), resto por defecto
corregir el httpd.conf para que refleje el toba.conf de la nueva versión
corregir el toba.conf para que refleje el alias de mi_proyecto
Alias /mi_proyecto/1.0 “C:/toba_2.3/proyectos/mi_proyecto/www”
cambiar por:
Alias /alias1 “C:/toba_2.3/proyectos/mi_proyecto/www”
reiniciar Apache
mover la carpeta de mi_proyecto a c:\toba_2.3\proyectos
eliminar de mi_proyecto la carpeta metadatos_compilados
actualizar mi_proyecto con la nueva version ya migrada a la version 2.3 en desarrollo (SVN Update)
ejecutar en la consola (la de 2.3): toba proyecto cargar -p mi_proyecto
ejecutar en la consola: toba proyecto compilar -p mi_proyecto
Nota: Cabe aclarar que los proyectos están funcionando, pero solo con el usuario toba y acceso Administrador.
ejecutar en la consola: toba instancia importar -d c:\toba_2.1 -r 1
-o-o-o-o-o-o- Acá se complicó porque tiró el siguiente error:
C:\Documents and Settings\Administrador>toba instancia importar -d c:\toba_2.1 r 1
…
ERROR ejecutando SQL:
[CODIGO]: 7
[SQLSTATE]: db_23503
[MENSAJE]: ERROR: inserción o actualización en la tabla
«apex_usuario_proyecto» viola la llave foránea «apex_usu_proy_fk_grupo_acc»
DETAIL: La llave (proyecto,usuario_grupo_acc)=(upso_proyecto1,mantenimiento)
no está presente en la tabla «apex_usuario_grupo_acc».
[SQL EJECUTADA]: COMMIT TRANSACTION;
No se me ocurre como seguir, o bien, que puede estar haciendose mal.
Adjunto el log de este comando.
Estoy haciendo esta prueba en una MV que es réplica de Producción, por suerte, para acomodar el machete, o alguna eventualidad como la que está sucediendo, pero urge la solución al problema. En desarrollo seguimos trabajando y tenemos que poder subir la información sin perder los datos de los usuarios y los perfiles.
Pruebas que he hecho, le saqué lo de usar_perfiles_propios en instancia.ini
Saqué el flag es_produccion.
Y probé con las 4 combinaciones posibles de esos 2 flags.
El problema está con la importación de la instancia.
Lo que quedaba pendiente en el machete (que se fue haciendo también entre las pruebas) fue:
editar bases.ini (c:\toba_2.3\instalacion)
- copiar los datos de la base propia de mi_proyecto del bases.ini de toba 2.1 al actual bases.ini
editar instancia.ini (c:\toba\instalacion\i__desarrollo), para mi_proyecto
- agregar usar_perfiles_propios=1
editar instalacion.ini (c:\toba\instalacion)
- corregir es_produccion=1
- agregar datos de smtp, igual que la anterior instalacion
copiar el archivo smtp.ini de c:\toba_2.1\instalacion a la misma carpeta de la nueva instalación.
En la instancia 2.1 tenes que quitar el flag usar_perfiles_propios antes de realizar la exportacion, de manera que los perfiles no se exporten a un archivo xml, sino a los archivos .sql como siempre.
Luego deberias seguir el procedimiento que me copiaste, solo un detalle:
- eliminar de mi_proyecto la carpeta metadatos_compilados
No es realmente necesario si vas a recompilar despues, igual sobre gustos no hay nada escrito :D.
La importacion de la instancia te falla porque alguno de los perfiles que se genero en produccion, no se exporto a la carpeta del proyecto (esto tiene que ver con el flag usar_perfiles_propios), por tanto cuando quizo incluir la asociacion entre usuario y perfil, no lo encontro.
instalar la nueva versión, desarrollador XXXX, clave postgres = XXXX, clave usuario Toba = XXXX (la misma que antes), resto por defecto
corregir el httpd.conf para que refleje el toba.conf de la nueva versión
corregir el toba.conf para que refleje el alias de mi_proyecto
Alias /mi_proyecto/1.0 “C:/toba_2.3/proyectos/mi_proyecto/www”
cambiar por:
Alias /alias1 “C:/toba_2.3/proyectos/mi_proyecto/www”
reiniciar Apache
copiar la carpeta de mi_proyecto a c:\toba_2.3\proyectos
eliminar de mi_proyecto la carpeta metadatos_compilados
ejecutar en la consola (la de 2.3): toba proyecto importar -p mi_proyecto -d c:\toba_2.1
ejecutar en la consola: toba proyecto publicar -p mi_proyecto
actualizar mi_proyecto con la nueva version ya migrada a la version 2.3 en desarrollo (SVN Update). N.del A.: Hubo muchos MERGE pero la version es la misma.
ejecutar en la consola: toba proyecto regenerar -p mi_proyecto
ejecutar en la consola: toba proyecto compilar -p mi_proyecto
Esto a grandes rasgos, salvo algún eventual error de perfiles que hubo que ingresar, abrir, y guardar (por cambio en los items y operaciones del proyecto), pudo hacerse. Cabe aclara que es un “instructivo” que redunda algunas cosas y solo para ambiente windows. En linux tiene otras cosillas a tener en cuenta.
tenes alma de faquir vos no? :D… me parece que te complicaste y arriesgaste de mas.
Migrar el proyecto en produccion no era necesario, solo tenias que asegurarte que se mantuvieran eran los grupos de acceso nuevos que se hubieran creado alli.
Lo cual podias conseguir copiando el directorio metadatos/permisos de la version vieja a la nueva (una vez exportados los metadatos), e incluso hacer un revert de los archivos sobreescritos de ultima, para que a futuro no te tire conflicto svn.
Esta vez con esfuerzo te salio bien… pero sabe que estas jugando con fuego y alcohol, esos merge masivos son propensos a que algo quede cruzado.
De nuevo, no deberias tener merge masivos en una actualizacion de version.
El problema en este caso, que no me permitió hacer un cargar de la versión ya migrada en desarrollo fue que uno de los proyectos tenía diferencias de items/operaciones, por ende saltaban los perfiles por todos lados y no concretaba la carga. No me quedó otra que simular un “desarrollo” en producción.
Igual en el medio hay mil backups!
Gracias! como siempre!