Gestionar cambios en la base de datos entre un proyecto Rails y Java

Question

En un nuevo trabajo que comencé, tenemos una aplicación Java que maneja la mayor parte del trabajo pesado en la lógica comercial central, y también tenemos una aplicación Rails que, por supuesto, maneja la interfaz web de este servidor. Ambos acceden a la misma base de datos.

Hasta ahora, la mayor parte del enfoque se ha centrado en la aplicación Java y, como tal, no hay migraciones en el proyecto Rails. El sql para actualizar la base de datos compartida se administra en un archivo como changes.sql.

Como puedes imaginar, esto dificulta un poco el desarrollo.

Mi idea inicial era combinar las bases de código para el proyecto Java y la aplicación Rails, porque hay una dependencia allí, y administrar ese archivo SQL en la fuente. Sin embargo, pensé en preguntar aquí para ver si alguien más había abordado este problema con cierto grado de éxito.

Answer 1

Un enfoque es utilizar las herramientas de migración de rieles, generar los archivos DDL para la base de datos y usar Hibernate para actualizar los objetos Java relacionados con entidades de bases de datos específicas. Realmente no dice cómo gestiona los cambios en la base de datos en el lado de Java o si usa un ORM, pero ciertamente puede sincronizar los dos con un poco de trabajo.

O puede ir al revés y dejar que las definiciones de Java controlen los cambios en el lado de Rails.

Creo que la clave para hacer esto con éxito es seleccionar una de las dos plataformas como su "modelador de base de datos principal" y desarrolle el proceso para migrar ese modelo a la otra plataforma. Intentar permitir cambios de ambos solo causará dolores de cabeza.

Answer 2

Tenemos una estructura de proyecto similar: base de datos compartida con aplicaciones Java y Rails como clientes. Defendí y obtuve la aceptación de usar el mecanismo de migración de rieles para manejar los cambios en la base de datos. Se necesita un poco de defensa de los rieles y cierta disposición a ayudar, pero el equipo de Java también está escribiendo sus propias migraciones.

Tenemos algunos casos en los que usamos procedimientos almacenados y tipos de columnas específicos de la base de datos, por lo que cambiamos los rails environment.rb para usar sql para crear la base de datos de prueba.

  # Use SQL instead of Active Record's schema dumper when creating the test database.
  # This is necessary if your schema can't be completely dumped by the schema dumper,
  # like if you have constraints or database-specific column types
  config.active_record.schema_format = :sql

En el lado positivo, la administración de sql con migraciones hace que las pruebas de rieles y la configuración estén limpias para usted. La desventaja es que algunos de los archivos de migración simplemente no son tan bonitos (por ejemplo, no puede usar el DSL de migración para generar procedimientos almacenados, por lo que debe ejecutar% {blah} en sus migraciones).

Solo recuerde mantener abiertas las líneas de comunicación entre los equipos. Me gusta el hecho de que " despliegue de producción de cap: migraciones " simplifica la actualización de la base de datos de producción.

Answer 3

Gracias Steve

En el lado de Java, están utilizando Hibernate, pero con un proceso de actualización manual de SQL.

Estoy de acuerdo, que debería ser uno u otro. Cuanto más lo pienso, agregar otra aplicación / módulo / base de código para administrar solo la base de datos es definitivamente la idea equivocada.

Gracias