Gestione delle modifiche al database tra un progetto Rails e Java

Question

In un nuovo lavoro che ho iniziato, disponiamo sia di un'applicazione Java che gestisce la maggior parte del lavoro pesante nella logica di business principale, sia di un'applicazione Rails che, ovviamente, gestisce l'interfaccia web con questo server. Entrambi accedono allo stesso database.

Fino ad ora, gran parte dell'attenzione è stata focalizzata sull'applicazione Java e, come tale, non ci sono migrazioni nel progetto Rails. Il sql per aggiornare il database condiviso è gestito in un file come changes.sql.

Come puoi immaginare, questo rende un po 'difficile lo sviluppo.

Il mio pensiero iniziale era di combinare i codebase per il progetto Java e l'applicazione Rails, perché lì c'è una dipendenza e per gestire quel file SQL nell'origine. Tuttavia, ho pensato di chiedere qui per vedere se qualcun altro avesse affrontato questo problema con un certo grado di successo.

Answer 1

Un approccio consiste nell'utilizzare gli strumenti di migrazione delle rotaie, generare i file DDL per il database e utilizzare Hibernate per aggiornare gli oggetti Java relativi a entità di database specifiche. In realtà non dici come gestisci le modifiche al database sul lato Java o se usi un ORM, ma puoi sicuramente sincronizzare i due con un po 'di lavoro.

Oppure puoi fare il contrario e lasciare che le definizioni Java controllino le modifiche sul lato Rails.

Penso che la chiave per farlo con successo sia selezionare una delle due piattaforme come il tuo "modellatore di database primario" e sviluppare il processo per migrare quel modello sull'altra piattaforma. Il tentativo di consentire modifiche da entrambi causerà solo mal di testa.

Answer 2

Abbiamo una struttura di progetto simile: database condiviso con applicazioni java e rails come client. Ho sostenuto e ottenuto il buy-in per utilizzare il meccanismo di migrazione delle rotaie per gestire le modifiche al database. Ci vuole un po 'di sostegno per le rotaie e una certa disponibilità ad aiutare, ma il team di Java sta anche scrivendo le proprie migrazioni.

Abbiamo alcuni casi in cui utilizziamo procedure memorizzate e tipi di colonne specifici del database, quindi abbiamo cambiato rails environment.rb per usare sql per creare il database di test.

  # 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

Sul lato positivo, la gestione di sql con le migrazioni rende i test delle rotaie e l'installazione puliti per te. Il rovescio della medaglia è che alcuni dei file di migrazione non sono così belli (ad esempio, non è possibile utilizzare il DSL di migrazione per generare procedure archiviate, quindi è necessario eseguire questi% {blah} nelle migrazioni).

Ricorda solo di tenere aperte le linee di comunicazione tra le squadre. Mi piace il fatto che "cap produzione dispiega: migrazioni" rende semplice l'aggiornamento del database di produzione.

Answer 3

Grazie Steve

Sul lato Java, stanno utilizzando Hibernate, ma con un processo di aggiornamento SQL manuale.

Sono d'accordo, che dovrebbe essere l'uno o l'altro. Più ci penso, aggiungere ancora un'altra applicazione / modulo / base di codice per gestire solo il database è sicuramente un'idea sbagliata.

Grazie