Gestion des modifications de base de données entre un projet Rails et Java

Question

Lors d’une nouvelle tâche que j’ai commencée, nous avons à la fois une application Java qui gère la majeure partie des tâches lourdes de la logique métier centrale et une application Rails qui gère bien sûr l’interface Web de ce serveur. Tous deux accèdent à la même base de données.

Jusqu’à présent, l’application Java était au centre des préoccupations. Par conséquent, il n’ya pas de migration dans le projet Rails. Le SQL pour mettre à jour la base de données partagée est géré dans un fichier tel que changes.sql.

Comme vous pouvez l’imaginer, cela le rend un peu difficile à développer.

Mon idée initiale était de combiner les bases de code du projet Java et de l'application Rails, car il existe une dépendance, et de gérer ce fichier SQL dans le source. Cependant, je pensais que je demanderais ici pour voir si quelqu'un d'autre avait abordé cette question avec un certain succès.

Answer 1

Une approche consiste à utiliser les outils de migration de rails, à générer les fichiers DDL de la base de données et à utiliser Hibernate pour mettre à jour les objets Java liés à des entités de base de données spécifiques. Vous ne dites pas vraiment comment vous gérez les modifications de la base de données côté Java ni si vous utilisez un ORM, mais vous pouvez certainement synchroniser les deux avec un peu de travail.

Vous pouvez également faire l'inverse et laisser les définitions Java contrôler les modifications du côté de Rails.

Je pense que la solution pour y parvenir consiste à sélectionner l'une des deux plates-formes comme "modélisateur de base de données primaire". et développez le processus pour migrer ce modèle vers une autre plateforme. Tenter d’autoriser des modifications des deux ne fera que causer des maux de tête.

Answer 2

Nous avons une structure de projet similaire: base de données partagée avec des applications java et rails en tant que clients. J'ai préconisé et obtenu l'adhésion à l'utilisation du mécanisme de migration des rails pour gérer les modifications de base de données. Il faut un peu de riposte et une volonté d'aider, mais l'équipe Java écrit également ses propres migrations.

Dans certains cas, nous utilisons des procédures stockées et des types de colonne spécifiques à la base de données. Nous avons donc modifié le fichier rails environment.rb afin qu'il utilise SQL pour créer la base de données de 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

La gestion du SQL avec les migrations facilite le test et la configuration des rails pour vous. L’inconvénient est que certains fichiers de migration ne sont tout simplement pas aussi beaux (vous ne pouvez pas utiliser le DSL de migration pour générer des procédures stockées; vous devez donc exécuter% {blah} dans vos migrations).

N'oubliez pas de garder les lignes de communication ouvertes entre les équipes. J'aime le fait que "cap production déploie: migrations". simplifie la mise à jour de la base de données de production.

Answer 3

Merci Steve

Du côté de Java, ils utilisent Hibernate, mais avec un processus de mise à jour SQL manuel.

Je suis d’accord pour dire que ce devrait être l’un ou l’autre. Plus j'y pense, ajouter une autre application / module / code pour gérer uniquement la base de données est une mauvaise idée.

Merci