Управление изменениями базы данных между Rails и Java-проектом

Question

На новой работе, которую я начал, у нас есть Java-приложение, которое выполняет большую часть тяжелой работы в основной бизнес-логике, и у нас также есть приложение Rails, которое, конечно, обрабатывает веб-интерфейс с этим сервером. Оба они имеют доступ к одной и той же базе данных.

До сих пор основное внимание уделялось Java-приложению, и поэтому в проекте Rails нет миграций. SQL для обновления общей базы данных управляется в файле, подобном changes.sql.

Как вы понимаете, это несколько усложняет разработку.

Моей первоначальной мыслью было объединение кодовых баз для проекта Java и приложения Rails, потому что там есть зависимость, и управление этим файлом SQL в исходном коде. Тем не менее, я подумал, что я хотел бы попросить здесь, чтобы кто-нибудь еще с этой долей успеха справился с этой проблемой.

Answer 1

У нас похожая структура проекта: общая база данных с приложениями java и rails в качестве клиентов. Я поддержал и получил поддержку, чтобы использовать механизм миграции рельсов для обработки изменений в базе данных. Требуется немного адвокатуры рельсов, и некоторая готовность помочь, но команда Java также пишет свои собственные миграции.

У нас есть несколько случаев, когда мы используем хранимые процедуры и типы столбцов, специфичные для базы данных, поэтому мы изменили файл rails environment.rb, чтобы использовать sql для создания тестовой базы данных.

  # 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

С другой стороны, управление sql с миграциями делает тестирование и настройку rails чистыми для вас. Недостатком является то, что некоторые из файлов миграции просто не так хороши (например, вы не можете использовать DSL миграции для генерации хранимых процедур, поэтому вы выполняете эти% {blah} в своих миграциях).

Только не забывайте держать линии связи открытыми между командами. Мне нравится тот факт, что «Cap Production Deployment: Migration» делает обновление производственной базы данных очень простым.

Answer 2

Один из подходов состоит в том, чтобы использовать инструменты миграции rails, генерировать файлы DDL для базы данных и использовать Hibernate для обновления объектов Java, которые относятся к конкретным объектам базы данных. Вы на самом деле не говорите, как вы управляете изменениями базы данных на стороне Java или используете ли вы ORM, но вы, безусловно, можете синхронизировать их с небольшой работой.

Или вы можете пойти другим путем и позволить определениям Java управлять изменениями на стороне Rails.

Я думаю, что ключом к успешному выполнению этой задачи является выбор одной из двух платформ в качестве «основного разработчика моделей базы данных» и разработка процесса переноса этой модели на другую платформу. Попытка разрешить изменения от обоих приведет только к головным болям.

Answer 3

Спасибо, Стив

На стороне Java они используют Hibernate, но с процессом обновления SQL вручную.

Я согласен, что это должен быть один или другой. Чем больше я думаю об этом, тем не менее, добавление еще одного приложения / модуля / кодовой базы для управления только базой данных - определенно неправильная идея.

Спасибо