Migraciones de datos

Ejecuta una migración de datos concreta incluida en una versión.

Cómo funciona

Algunos cambios no se pueden expresar en SQL: reescribir el contenido de los eventos a un nuevo formato binario, normalizar datos heredados, volver a calcular campos derivados. Cada uno de esos cambios se incluye en la aplicación como una migración programada: una tarea de migración.

Ejecutas una tarea de migración cada vez, por su nombre. A propósito, no existe un modo de «ejecutarlo todo»: pasar todas las migraciones a la vez no tiene límites y afecta a todos los espacios de trabajo, y antes bastaba con dejar un campo del formulario en blanco para hacerlo. El campo Tarea es obligatorio y su desplegable muestra exactamente las tareas de migración que registra la versión desplegada.

Después, una ejecución:

1. Muestra una vista previa por defecto: con Aplicar desactivado, la tarea informa de lo que cambiaría sin escribir nada. Lee primero la vista previa; para eso está
2. Solo escribe cuando lo indicas: activa Aplicar para guardar los cambios. El formulario te obliga a marcar Entiendo que esto escribe cambios que no se pueden revertir antes de enviarlo, porque aplicar escribe en todos los espacios de trabajo del ámbito y no se puede revertir
3. Reconstruye proyecciones si hace falta: una tarea cuyos cambios tienen que recoger las proyecciones lo solicita como paso posterior. Cuando termina la ejecución, se programa Reconstruir proyecciones de empleados como una ejecución nueva. Aparece en la lista de ejecuciones de tareas como una entrada aparte, que solo empieza cuando ha terminado la ejecución de las migraciones

Cuándo se ejecuta

La tarea la lanza un operador. Nunca empieza por sí sola: ni de forma programada ni al arrancar la aplicación. Lánzala cuando haga falta una migración, desde Administración › Ejecuciones de tareas. Solo se puede ejecutar desde el espacio de trabajo del sistema y no aparece en ningún otro espacio de trabajo.

No empieza automáticamente porque entonces cada copia en ejecución de la aplicación pondría en cola su propia ejecución, y varias ejecuciones que cambian los mismos datos a la vez ralentizan la base de datos.

Parámetros

La API programática acepta las mismas opciones, más workspace_id para limitar una tarea con ámbito a un espacio de trabajo; el formulario de lanzamiento no tiene selector de espacio de trabajo.

{"jobs":["migrations"],"options":{"tasks":["<task-name>"]}}
{"jobs":["migrations"],"options":{"tasks":["<task-name>"],"apply":true}}

Las opciones con las que se lanzó una ejecución se muestran en la columna Parámetros de la lista de ejecuciones, que está oculta por defecto: actívala desde el menú de columnas para distinguir dos ejecuciones de la misma tarea.

Resultados de la tarea

El resultado incluye dry_run (lo contrario de Aplicar) y una clave por cada tarea de migración ejecutada:

Un nombre que no es una tarea registrada aparece como "unknown task" junto a ese nombre.

Cuando se ejecuta una tarea marcada como «reconstruye proyecciones», el resultado también incluye next_jobs: ["rebuild-employee-projections"] y esa tarea se programa automáticamente.

Volver a ejecutar

Todas las tareas registradas se pueden volver a ejecutar cuando quieras. Cada tarea deja fuera los datos que ya se han migrado, así que volver a ejecutarla tras un éxito parcial continúa donde lo dejó la ejecución anterior, y volver a ejecutar una tarea terminada no cambia nada y no informa de nada afectado.

Solución de problemas