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

Question

un nouvel emploi, j'ai commencé, nous avons à la fois une application Java qui gère la plupart des charges lourdes dans la logique métier de base, et nous avons aussi une application Rails que bien sûr poignées la interface web vers ce serveur. Les deux accèdent à la même base de données.

Jusqu'à présent, la plupart de l'accent a été mis sur l'application Java, et en tant que tel, il n'y a pas de migrations dans le projet Rails. Le sql pour mettre à jour la base de données partagée est géré dans un fichier comme changes.sql. Comme vous pouvez l'imaginer, cela le rend un peu difficile à développer.

Ma première pensée était de combiner les bases de code pour le projet Java et l'application Rails, car il y a une dépendance là-bas, et de gérer ce fichier SQL dans la source. Cependant, j'ai pensé que je demanderais ici de voir si quelqu'un d'autre avait abordé cette question avec un certain degré de succès.

Answer 1

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

Ou vous pouvez aller dans l'autre sens et laisser les définitions Java contrôler les changements sur le côté Rails.

Je pense que la clé de cette action est avec succès pour sélectionner une des deux plates-formes comme votre « modeleur de base de données primaire » et développer le processus de migration de ce modèle à l'autre plate-forme. Tenter d'autoriser les changements des deux ne causera que des maux de tête.

Answer 2

Merci Steve

Du côté Java, ils utilisent Hibernate, mais avec un processus manuel de mise à jour de SQL. Je suis d'accord, que ce devrait être l'un ou l'autre. Plus j'y pense, ajouter une autre application/module/codebase pour gérer seulement la base de données est définitivement une mauvaise idée.

Merci

Answer 3

Nous avons une structure de projet similaire: base de données partagée avec Java et rails applications en tant que clients. J'ai préconisé et obtenu l'adhésion pour utiliser le mécanisme de migration de rails pour manipuler des changements de base de données. Cela demande un peu de plaidoyer et une certaine volonté d'aider, mais l'équipe java écrit aussi ses propres migrations.

Nous avons des cas où nous utilisons des procédures stockées et les types de colonnes spécifiques de base de données, nous avons donc changé les rails environment.rb utiliser SQL pour créer la base de données de test. Du côté positif, la gestion du sql avec les migrations rend le test et la configuration des rails plus nettes pour vous. L'inconvénient est que certains fichiers de migration ne sont tout simplement pas si jolis (par exemple, vous ne pouvez pas utiliser la migration DSL pour générer des procédures stockées, donc vous avez ces exécuter% {blah} dans vos migrations).

N'oubliez pas de garder les lignes de communication ouvertes entre les équipes. J'aime le fait que "la production de casquettes deploy: migrations" rend la mise à jour de la base de données de production plus simple.