Algunas ETLs como la de tourism utilizan la clase sqlFileStore para permitir guardar los datos a un fichero SQL en lugar de directamente a Orion.
Esto es útil para pruebas (para comprobar si los datos de LUCA son correctos y no dan fallos al cargar, que casi siempre los dan), y también para cargar manualmente los datos, en lugar de por orion (lo que suele ahorrar varias horas de ejecución).
Sin embargo, en la última versión de la vertical de turismo, se ha pasado al sink mutable, que sqlFileStore no soporta. Así que la ETL ya no se puede usar para cargas manuales, solo para cargas por orion.
Se podría cambiar el sqlFileStore para soportar un nuevo parámetro, mutable_id, que permita soportar las tablas mutable, modificando el sql generado para que añada un ON CONFLICT DO UPDATE ... a las sentencias SQL generadas.
Aunque no tengo 100% de todo el contexto :), suena a mejora interesante que no impacta en la compatibilidad hacia atrás de la librería, así que por mi parte, adelante.
Algunas ETLs como la de tourism utilizan la clase
sqlFileStore
para permitir guardar los datos a un fichero SQL en lugar de directamente a Orion.Esto es útil para pruebas (para comprobar si los datos de LUCA son correctos y no dan fallos al cargar, que casi siempre los dan), y también para cargar manualmente los datos, en lugar de por orion (lo que suele ahorrar varias horas de ejecución).
Sin embargo, en la última versión de la vertical de turismo, se ha pasado al sink mutable, que
sqlFileStore
no soporta. Así que la ETL ya no se puede usar para cargas manuales, solo para cargas por orion.Se podría cambiar el
sqlFileStore
para soportar un nuevo parámetro,mutable_id
, que permita soportar las tablas mutable, modificando el sql generado para que añada unON CONFLICT DO UPDATE ...
a las sentencias SQL generadas.