tutorial instalar glasses descargar como caracteristicas flyway

instalar - flyway tutorial



La mejor manera de crear scripts SQL "específicos para bases de datos" con Flyway (2)

Comencé a usar Flyway en mi proyecto actual para migraciones de base de datos y me gusta mucho. Actualmente uso Oracle en PROD y Derby en TEST-Environment.

Muy pronto, me encontré con el problema de los comandos SQL específicos de la base de datos, por ejemplo,

  • ALTER TABLE T1 MODIFY F1 VARCHAR(256); en Oracle vs
  • ALTER TABLE T1 ALTER F1 SET DATA TYPE VARCHAR(256); en derby.

No puedo ver una forma de escribir un "tipo de dato de columna de modificación de tabla neutral de proveedor".

¿Cuál es la mejor manera de lidiar con este problema usando Flyway?


Las diferencias en SQL entre Oracle y algunas de estas bases de datos de escritorio son menores. ¿Es posible que un desarrollador inserte un código personalizado para realizar una eliminación dinámica ligera de SQL en el tiempo de ejecución en función del entorno (por ejemplo, eliminar la designación de espacio de tablas)?

Prefiero este enfoque a confiar en cada desarrollador para mantener manualmente sincronizados dos conjuntos de SQL.


Puede utilizar la propiedad flyway.locations.

En prueba se vería así:

flyway.locations=sql/common,sql/derby

y en prod:

flyway.locations=sql/common,sql/oracle

Entonces podría tener las declaraciones comunes (V1__Create_table.sql) en común y diferentes copias de las declaraciones específicas de DB (V2__Alter_table.sql) en las ubicaciones específicas de db.

Una solución aún mejor, en mi opinión, es tener la misma base de datos en prod y test. Sí, pierde un poco de rendimiento, pero, por otro lado, también elimina otra diferencia (y una posible fuente de errores) entre los entornos.