2009-12-28 2 views
15

Я работаю над приложением многопользовательских рельсов, используя схемы PostgreSQL для разных клиентов. Миграция Rails не работает с несколькими схемами из коробки, поэтому я выполнил следующую команду rake, чтобы перенести все схемы и, похоже, работает. Мой вопрос в том, что другие реализовали лучшие и более элегантные решения. Я также был бы очень доволен хорошим учебным пособием, включая примеры кода rails для PostgreSQL с использованием нескольких схем. До сих пор я только нашел хорошую презентацию на тему http://aac2009.confreaks.com/06-feb-2009-14-30-writing-multi-tenant-applications-in-rails-guy-naor.html и пример того, что я стремлюсь к tomayko.com/writings/rails-multiple-connectionsПереходы Rails для схем postgreSQL

desc 'Migrates all postgres schemas' 
task :schemas do 
    # get all schemas 
    env = "#{RAILS_ENV}" 
    config = YAML::load(File.open('config/database.yml')) 
    ActiveRecord::Base.establish_connection(config[env]) 
    schemas = ActiveRecord::Base.connection.select_values("select * from pg_namespace where nspname != 'information_schema' AND nspname NOT LIKE 'pg%'") 
    puts "Migrate schemas: #{schemas.inspect}" 
    # migrate each schema 
    schemas.each do |schema| 
    puts "Migrate schema: #{schema}" 
    config = YAML::load(File.open('config/database.yml')) 
    config[env]["schema_search_path"] = schema 
    ActiveRecord::Base.establish_connection(config[env]) 
    ActiveRecord::Base.logger = Logger.new(STDOUT) 
    ActiveRecord::Migrator.migrate('db/migrate', ENV["VERSION"] ? ENV["VERSION"].to_i : nil) 
    end 
end 
+0

Liquibase действительно работает со схемами, насколько я знаю – Janning

+1

@Janning Liquibase - это не решение, которое работает с моделями ActiveRecord, которые используют рельсы. – lillq

ответ

0

Я не уверен, если я получил вопрос прав, но разве вам не нужно объявлять еще несколько окружений в вашем database.yml с различной «базой данных», указанной в каждом?

+2

Схемы в postgres находятся в базе данных. I. Одна база данных может иметь много схем. – lillq

8

У меня есть библиотека schema_utils, который я использую, и имеет следующий метод для обработки миграции:

def self.with_schema(schema_name, &block) 
    conn = ActiveRecord::Base.connection 
    old_schema_search_path = conn.schema_search_path 
    conn.schema_search_path = schema_name 
    begin 
     yield 
    ensure 
     conn.schema_search_path = old_schema_search_path 
    end 
    end 

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

... 
schemas.each do |schema| 
    SchemaUtils.with_schema(schema) do 
    #Put migration code here 
    #e.g. add_column :xyz, ... 
    end 
end 

Потому что я, как правило, отображение схем для учета кодов я следующее:

Account.for_each do |account| 
    SchemaUtils.with_schema(account.code) do 
    #Put migration code here 
    end 
end 
0

Я написал pg_migrate из-за этих сценариев, то есть ситуаций, в которых несколько приложений используют одну и ту же базу данных. Вероятно, Rails способ справиться с этим (двигатели?), Но у меня слишком часто есть другое приложение, которое не является Rails, которому также нужна база данных ... то что?

В этом случае ключевой функцией pg_migrate является создание рубинового драгоценного камня; поэтому становится возможным поддерживать схему базы данных отдельно от всех нисходящих приложений, но все могут ссылаться на нее.

В вашем Rails Gemfile, после того, как вы построили рубиновый камень, используя команду «пакет» pg_migrate, вы можете сделать:

gem 'my_db', gem 'jam_db', :path=> "../my_db/gem_package" 
0

Проверьте apartment драгоценный камень, который был построен только для этой цели. Это великолепно.