Миграции с конфигурацией нескольких баз данных Rails

Я разрабатываю приложение Rails, в котором буду использовать 2 разные базы данных. А именно, один для хранения учетных данных пользователя, а другой - для хранения данных другого типа. Я настроил свой файл database.yml для приема двух разных баз данных для каждой среды. Выглядит это так:

<% %w(development test production).each do |env| %>
data_<%= env %>:
  adapter: sqlite3
  database: db/data/<%= env %>.sqlite3
  pool: 5
  timeout: 5000

users_<%= env %>:
  adapter: sqlite3
  database: db/users/<%= env %>.sqlite3
  pool: 5
  timeout: 5000
<% end %>

Я также создал двухуровневые модели, по одной для каждого подключения к базе данных, а именно:

class UsersBase < ActiveRecord::Base
  establish_connection "users_#{RAILS_ENV}"
end

и

class DataBase < ActiveRecord::Base
  establish_connection "data_#{RAILS_ENV}"
end

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

Однако теперь у меня возникла проблема при попытке запустить rake db: migrate. Задача rake не находит базу данных разработки по умолчанию (которая по соглашению должна называться development в database.yml). Мой вопрос в том, можно ли каким-то образом передать это в качестве параметра для задачи rake или, что еще лучше, сообщить Rails где-нибудь в сценарии конфигурации, что есть 2 базы данных или что имя базы данных разработки по умолчанию изменено?


person Victor Blaga    schedule 05.11.2011    source источник


Ответы (2)


Вы определяете эти базы данных:

  1. data_development
  2. users_development
  3. data_test
  4. users_test
  5. data_production
  6. users_production

Rails в первую очередь ищет определения базы данных, соответствующие имени среды (разработка, тестирование, производство). Для базы данных данных просто используйте эти имена, и база данных данных будет перенесена.

пытаться

<% %w(development test production).each do |env| %>
  <%= env %>:
  adapter: sqlite3
  database: db/data/<%= env %>.sqlite3
  pool: 5
  timeout: 5000

users_<%= env %>:
  adapter: sqlite3
  database: db/users/<%= env %>.sqlite3
  pool: 5
  timeout: 5000
<% end %>

все базы данных "data_X" просто несут имя среды. Это то, чего ожидает Rails, и поэтому миграции будут работать с ними.

Это может оставить вас в стороне, хотя в отношении миграции пользовательских dbs. Я не думаю, что миграции Rails предназначались для использования таким образом - миграции 2 dbs в одной среде.

Тем не менее, я бы попробовал. Вот изменение модели, необходимое для согласования с изменением database.yml выше:

class DataBase < ActiveRecord::Base
end

Фактически, вы можете полностью отказаться от DataBase и просто позволить прежним моделям DataBase напрямую расширять ActiveRecord :: Base.

Интересно увидеть, что вы найдете, если попробуете это.

person ffoeg    schedule 09.11.2011
comment
Запоздалая мысль ... почему эта база данных вообще разделяет? Одно приложение, которое управляет двумя отдельными базами данных, возможно, но выходит за рамки соглашений Rails. Конечно, это возможно, но не без боли и головной боли. Честно говоря, если бы один из моих разработчиков предложил этот сценарий, я бы отправил их обратно на чертежную доску. - person ffoeg; 09.11.2011
comment
Дело в том, что приложение Rails является частью гораздо более крупной системы, которая включает в себя другие компоненты, такие как поисковые роботы, анализ данных, систему, собирающую статистику и т. Д. Пользовательская база данных будет практически совместно использоваться всеми компонентами системы (а именно одним может создавать пользователей за пределами веб-приложения Rails), а база данных будет использоваться только для обслуживания веб-контента. Таким образом, я бы очень хотел, чтобы они были разделены ... - person Victor Blaga; 10.11.2011
comment
Хотя, возможно, было бы лучше каким-то образом скопировать соответствующую часть пользовательских данных из таблицы базы данных пользователей в базе данных веб-приложения и использовать ее для входа и выхода - однако, возможно, в этом случае у меня возникнут проблемы с синхронизацией ... - person Victor Blaga; 10.11.2011
comment
Для меня это звучит так, как будто база данных пользователей должна быть службой, используемой этими системами. API или тому подобное. Если база данных пользователей просто фиксирует идентификацию, аутентификацию и другие роли, я бы сделал службу ldap доступной для всех. Путь, который вы выбрали, приносит с собой боль, которая никогда не исчезнет. - person ffoeg; 27.11.2011

Я написал pg_migrate для этого варианта использования. Вы можете определять свои схемы вне вашего приложения Rails с помощью этого проекта, но при этом изначально интегрировать его с вашим приложением Rails (pg_migrate может выводить «жемчужину схемы», то есть просто ваши схемы и class / cli для его миграции). Использование этого подразумевает удаление db: migrate как часть процесса разработки.

Веб-приложение не обязательно «владеет» схемой. Кроме того, вы можете программировать на нескольких языках.

Но только для Postgres.

person sethcall    schedule 31.07.2012