Buenas tardes,
Si bien ya les cargamos un GDS adjuntando el archivo de logs, quería consultarles cómo es el proceso para resolver los conflictos irresolubles. Estamos con la actualización de Gestión de la v3.16.2 a la v3.20.1 y nos aparecieron 54 conflictos irresolubles. ¿Esto tenemos que revisarlos uno por uno por nuestra cuenta o le pasamos los errores a ustedes y nos ayudan?
Agustín
Gracias
Hola Agustín,
Estuvimos mirando el log de conflictos que adjuntaron a la solicitud. Hay dos tipos de errores fatales:
Saludos, Florencia.
Hola Florencia,
Si, probablemente tengamos personalizaciones viejas que se hicieron con id_desarrollador = 0. Más allá de eso, siempre lo cambiamos desde instalacion.ini, no sabiamos de la existencia de ese comando de toba.
En los casos de errores de primary key, como lo resolvemos? Supongo que tenemos que setearle a las personalizaciones un id distinto. Se hace modificandolo directo desde los xml?, desde la base?. Y qué id tendriamos que agregarle?, de alguna secuencia en particular?
Agustín
Agustín,
Una vez corregido el ID de desarrollador, yo identificaría los casos y desde Toba-Editor borraría el objeto y lo volvería a crear para que asigne un nuevo identificador:
Si en cambio lo hacen a mano sobre los archivos .sql de los metadatos deben chequear que no haya referencia en otros objetos a esos identificadores. Respecto al valor, si el ID de desarrollador es 603, por ejemplo, el primer valor que asignará es 603000001.
Luego de las correcciones deben iniciar el proceso de migración nuevamente.
Saludos, Florencia.
Florencia,
Creo que la mejor forma es borrando los objetos de toba, porque a mano se nos puede pasar alguna referencia. Y qué hariamos con los casos en que modificamos un componente que ustedes borraron en la nueva versión?
Agustín,
Es proceso “artesanal”, deben identificar ustedes qué propósito tenía la personalización y si debe corregirse o ya no tiene sentido mantenerla (lo más probable si el objeto que personalizan desapareció). Pueden ir mirando y cualquier duda nos consultan. Los casos son muchos, te adjunto un documento con el detalle.
Saludos, Florencia.
errores fatales FK.txt (7.3 KB)
Buenas tardes,
Estoy teniendo un problema con alguno de los conflictos. Un ejemplo sería el conflicto del archivo comp_32000073.xml:
[F:3] El registro con clave objeto_proyecto:guarani,objeto:32000073,col_id:32000160 de la tabla apex_objeto_db_registros_col no existe.
Este error hace referencia a la columna ‘espacio’ de Datos Tabla sga_asignaciones. El problema viene pq en nuestra instalación el ID de esa columna es 4000011, y se está buscando el id 32000160. Ese id que busca es el correcto, porque revisé los metadatos_originales y esa columna tiene ese id. Veo que en el script que tenemos en metadatos PERSONALIZADOS, arriba de los insert dice “— INICIO Grupo de desarrollo 4”.
Puede ser que el ID dependa del grupo de desarrollador que lo creo?. De todos modos no entiendo cómo pudo haberse cambiado el ID. Habremos borrado y creado nuevamente la columna?. A alguien le pasó esto? La solución es modificando a mano el ID del metadato o hay otra manera?.
Dato extra: la columna ‘espacio’ se quitó en la 3.18, seguro que lo que intenta hacer la actualización es borrarla.
Espero su respuesta para poder seguir con la instalación. Gracias!!
Agustín,
Lo que está sucediendo es que, como parte de una personalización, tienen cambios en la columna ‘espacio’ (32000160) del datos_tabla para ‘sga_asignaciones’ (32000073). Esta columna dejó de existir cuando se modificó el modelo en la versión 3.18.0. Te dejo un post donde se explican un poco los cambios… Entiendo que esa personalización deja de tener sentido y puede eliminarse.
Saludos, Florencia.
Hola Florencia. Si, este caso es particular porque la columna la borran. Pero tengo otros casos en los que no se borran, y el id del elemento en los metadatos que personalizamos por algún motivo cambiaron. Entonces al haber cambiado los ID al actualizar no los encuentra y nos dan esos errores. Muestro otro ejemplo.
comp_37000065.xml:
El registro con clave objeto:37000065,externa_id:37000017,col_id:37000287,objeto_proyecto:guarani de la tabla apex_objeto_db_registros_ext_col no existe.
Col_id 37000287 es la columna ‘tipo_allegado’ del datos tabla de mdp_personas_allegados. Lo podemos ver en el metadato:
...VALUES (
'guarani', --objeto_proyecto
'37000065', --objeto
'37000287', --col_id
'tipo_allegado', --columna
'C', --tipo
'0', --pk
'', --secuencia
'1', --largo
NULL, --no_nulo
'1', --no_nulo_db
'0', --externa
NULL --tabla
);
Pero si me fijo en los metadatos de la instalación 3.16 actual, la cuál está personalizada, esa columna tiene otro ID:
VALUES (
'guarani', --objeto_proyecto
'37000065', --objeto
'4000003', --col_id
'tipo_allegado', --columna
'C', --tipo
'0', --pk
'', --secuencia
'1', --largo
NULL, --no_nulo
'1', --no_nulo_db
'0', --externa
'mdp_personas_allegados' --tabla
);
En todos los casos que nos sucede se cambiaron todos los id del objeto; en este ejemplo se cambiaron todos los de las columnas del Datos Tabla de mdp_personas_allegados.
El momento en el que se cambiaron los ID lo veo en el commit de git. Fue hace 1 año, pero no creo que hayamos trabajado de una manera distinta a la actual.
No entiendo por qué se cambiaron los ID de los elementos. Pasó alguna vez algo de esto?
Agustín,
Podés adjuntar esos metadatos perzonalizados? No se cuál es la personalización y en los conflictos no veo ese identificador (4000011)…
Saludos, Florencia.
Completé con un ejemplo. Pero te adjunto el metadato personalizado de /guarani/metadatos_originales/componentes/toba_datos_tabla/.
No ves ese conflicto. El conflicto es al buscar el id ‘37000400’. pero en nuestros metadatos ya no tienen ese ID, ahora es ‘4000011’.
dump_37000065_personalizado_3_16.sql (11.9 KB)
Agustín,
No, personalizar no cambia los identificadores de las columnas. Quizás en su momento se borraron las columnas del datos_tabla y se volvieron a levantar con la funcionalidad “Leer Metadatos DB”?
Saludos, Florencia.
Ah perfecto. Si, eso es lo único que se me ocurre que haya pasado. Yo creo que si modifico los metadatos a mano poniendole los id originales no vamos a tener problema, no?. O esos id pueden estar siendo usados en otro metadato y me generaria conflictos?
Agustín,
Si editás desde el archivo .sql correspondiente al metadato deberías verificar en ese mismo las referencias al identificador, por ejemplo desde una columna externa. No es mejor deshacer esos cambios y volver a personalizar de la manera correcta? Vos sabés en cada caso cuál fue la necesidad?
Saludos, Florencia.
No creo poder conseguir los cambios que se hicieron en todos los casos. Pero seguro que revisando Toba y la diferencia entre los metadatos puedo darme cuenta. Así lo hago deshaciendo los cambios y volver a personalizar como decís, para no generar ninguna inconsistencia.
Muchas gracias Florencia por la ayuda.
Buenas tardes!. Ya pudimos resolver los conflictos irresolubles. Ahrora continuamos con el siguiente paso:
./guarani esquema_pers importar
Ejemplo de error:
Existe un error de foreign keys, si cree que se trata de un problema de temporalidad ejecute el comando en modo transaccional.
Postgres dijo: ERROR: inserci�n o actualizaci�n en la tabla �apex_objeto_dependencias� viola la llave for�nea �apex_objeto_depen_fk_objeto_p�
DETAIL: La llave (proyecto, objeto_proveedor)=(guarani, 2511) no est� presente en la tabla �apex_objeto�..
El sql conflictivo es: INSERT INTO apex_objeto_dependencias (proyecto,dep_id,objeto_consumidor,objeto_proveedor,identificador) VALUES ('guarani','1362','2510','2511','editor'). Desea importar este cambio de cualquier manera? (Si o No)
Y acá entiendo que los errores que nos están apareciendo son los que al ejecutar el proceso de CONFLICTOS salian como Solubles. Por lo tanto también hay que analizar uno por uno. Son 180. Es así esto?
Gracias
Agustín,
En esos casos deberías responder “Si” a cada pregunta “Desea importar este cambio de cualquier manera? (Si o No)”. Es un tanto tedioso porque son muchos los casos pero el proceso debería completarse sin problemas.
Saludos, Florencia.
Que buena noticia, 186 eran muchos para revisar uno por uno. Puse todos que si, me fijé en una de las personalizaciones y al parecer se pasó bien. Muchas gracias!