Migrazioni di rotaie per gli schemi PostgreSQL

Question

Sto lavorando a un'applicazione di binari multi-tenant utilizzando gli schemi PostgreSQL per diversi client. Le migrazioni delle rotaie non funzionano con schemi multipli, quindi ho eseguito la seguente attività di rake per migrare tutti gli schemi e sembra funzionare. La mia domanda è se altri hanno implementato soluzioni migliori e più eleganti. Sarei anche molto contento di un buon tutorial che includa esempi di codice di rotaia per PostgreSQL che utilizza più schemi. Finora ho trovato solo una buona presentazione sul tema http://aac2009.confreaks.com/06-feb-2009-14-30-writing-multi-tenant-applications-in-rails-guy-naor.html e un esempio di quello che sto puntando 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

non sono sicuro se ho avuto la domanda giusta ma non è sufficiente dichiarare qualche altro ambiente nel tuo database.yml con "database" differente specificato in ognuno?

Answer 2

Ho un libreria schema_utils che ho usare e ha il seguente metodo per le migrazioni di movimentazione:

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 

Ho quindi utilizzare le migrazioni come normale in modo da poter continuare a chiamare rake: migrate Ora, nei tuoi migrazioni voi può usare:

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

perché tendo a essere mappare gli schemi per spiegare i codici faccio la seguente:

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

Answer 3

Ho scritto pg_migrate a causa di questi scenari, vale a dire situazioni in cui più applicazioni condividono lo stesso database. C'è probabilmente un modo Rails per gestire questo (motori?) Ma ho troppo spesso un'altra app che non è Rails che ha bisogno anche del database ... e poi?

In questo caso, la caratteristica chiave di pg_migrate è che può generare una gemma di rubino; quindi diventa possibile mantenere lo schema del database separatamente da tutte le applicazioni downstream, ma tutti possono farvi riferimento.

Nella tua Rails Gemfile, dopo che hai costruito la gemma rubino usando il comando di pg_migrate 'pacchetto', si può fare:

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

Answer 4

controllare la gemma apartment che è stato costruito solo per questo scopo. È brillante.