Мы будем выпускать вскоре сопутствующее применение Рельсов к нашему существующему приложению Рельсов. Мы будем запускать сопутствующее приложение вместе с нашим существующим приложением на тех же серверах.
Мой вопрос касается баз данных. Мой принимающий поставщик обычно настраивал бы 2-ю отличную базу данных для нового применения - secondappname_production. Однако есть ряд общих таблиц между заявлениями. Эти общие столы также сохраняются серией рабочих мест крона. Я хотел бы постараться не дублировать эти столы (и таким образом рабочие места крона) если вообще возможный.
Есть ли способ, которым я могу вставить эти общие столы, возможно, общая база данных, которую могут усилить оба приложения Рельсов? Какие-либо предложения относительно того, как настроить это или указатели документации?
Большое спасибо!
Править: Чтобы разъяснить, почему я не хочу запускать оба приложения из той же DB: у Обоих приложений есть модели того же имени (все же различные признаки моделей, и т.д.), таким образом, я предпочел бы не управлять обоими из той же DB....
Вы можете иметь некоторые модели в одной базе данных (те, которыми вы хотите поделиться), а другие - в собственной базе данных нового приложения (чтобы они не сталкивались с существующим приложением).
Чтобы указать другую базу данных для определенной модели, попробуйте что-нибудь вроде этого:
class SharedModelBase < ActiveRecord::Base
self.abstract_class = true
establish_connection(ActiveRecord::Base.configurations["shared_db_connection_#{RAILS_ENV}"])
end
Теперь используйте это в качестве базового класса для ваших разделяемых моделей, и вы должны быть готовы к работе.
Частью вашего вопроса является лучшая практика, так что пара других вариантов.
Один из вариантов - это даже не пытаться получить прямой доступ к db, а построить интеграцию между приложениями с помощью ActiveResource. Пусть оригинальное приложение предоставит RESTful интерфейс к этим таблицам, и использует его в новом приложении, а db вообще не будет совместно использоваться. Мне нравится этот вариант, но он может быть не очень умным в вашей ситуации.
Другой вариант - рефакторинг этих совместно используемых таблиц в их собственную базу данных, и предоставление обоим приложениям доступа к db. Вы даже можете закончить запись сервисов (например, успокоительного интерфейса) в эти общие данные, которые будут использоваться обоими приложениями, а затем вы будете хорошо развязаны.
Рассмотрим сложности, связанные с тем, когда изменяется эта разделяемая структура db. Если вы предоставляете общий доступ к таблицам напрямую, приложения для обеих реек могут быть изменены одновременно - вы связали свой график выпуска сейчас, эти приложения теперь соединены. Если вы обернете доступ к db в сервисах, это может обеспечить абстракцию, так как вы можете одновременно обслуживать и старую структуру, и новую структуру, установив новый обновленный сервис в то же самое время, что и интерфейс старого сервиса. Все зависит от вашего приложения, если такая сложность того стоит.