Migraciones de carriles para esquemas postgreSQL

Question

Estoy trabajando en una aplicación de rieles multi-tenant usando esquemas PostgreSQL para diferentes clientes. Las migraciones de rieles no funcionan con varios esquemas listos para usar, por lo que realicé la siguiente tarea de rake para migrar todos los esquemas y parece que funciona. Mi pregunta es si otros han implementado soluciones mejores y más elegantes. También estaría muy contento con un buen tutorial que incluye ejemplos de código de rieles para PostgreSQL usando múltiples esquemas. Hasta ahora sólo he encontrado una buena presentación sobre el tema http://aac2009.confreaks.com/06-feb-2009-14-30-writing-multi-tenant-applications-in-rails-guy-naor.html y un ejemplo de lo que estoy apuntando para tomayko.com/writings/rails-multiple-connections

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 

Answer 1

No estoy seguro si me dieron el pregunta correctamente, pero ¿no solo necesitas declarar algunos entornos más en tu database.yml con diferente "base de datos" especificada en cada uno?

Answer 2

que tienen una biblioteca schema_utils que yo uso y tiene el siguiente método para migraciones de manipulación:

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 

Luego uso migraciones como normal, de modo que pueda seguir llamando rastrillo: migrar Ahora, en sus migraciones se puede utilizar:

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

porque tiendo a ser el mapeo de esquemas para tener en cuenta los códigos hago lo siguiente:

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

Answer 3

Escribí pg_migrate debido a estos escenarios, es decir, situaciones en las que varias aplicaciones comparten la misma base de datos. Probablemente haya una forma de Rails de manejar esto (¿motores?) Pero también tengo a menudo otra aplicación que no es Rails que también necesita la base de datos ... ¿entonces qué?

En este caso, la característica clave de pg_migrate es que puede generar una gema de rubí; por lo que es posible mantener su esquema de base de datos por separado de todas las aplicaciones en sentido descendente, pero todos pueden hacer referencia a él.

En su Rieles Gemfile, después de que se ha construido la gema de rubíes con el comando de pg_migrate 'paquete', que puede hacer:

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

Answer 4

Comprobar la gema apartment que se ha construido sólo para ese fin. Es brillante.