Sono confuso su come configurare il DB in un'applicazione Rails 4.2 che utilizza Postgres e Heroku.Configurare correttamente un DB Postgres per un'applicazione Rails 4.2 su Heroku
Seguendo i consigli in this Heroku guide, si otterrà un config/database.yml come questo:
default: &default
adapter: postgresql
encoding: unicode
pool: 5
timeout: 5000
development:
<<: *default
database: app_name_development
test:
<<: *default
database: app_name_test
production:
<<: *default
database: app_name_production
Ma quando ho provato questo, il mio ambiente di sviluppo e di test sono state usando lo stesso DB come l'ambiente di gestione temporanea (notare il file ha nessuna configurazione per la stadiazione). Non va bene.
Questo Heroku guide for connecting to the DB in Ruby menzioni che eventuali applicazioni Rails prima 4.2 avrebbe loro database.yml di file sovrascritti da Heroku. Heroku analizzerà la variabile di ambiente DATABASE_URL e creerà un nuovo file database.yml.
Quindi penso che sia possibile abbandonare la configurazione in database.yml per qualsiasi ambiente che si dispone su Heroku, come la gestione temporanea e la produzione. Il tuo database.yml file could essentially look like Hound's (nota la mancanza di una configurazione di produzione).
development: &default
adapter: postgresql
encoding: unicode
database: app_development
pool: 5
test:
<<: *default
database: app_test
Ma dal momento che stiamo usando Rails 4.2, non credo Heroku sovrascrive il file database.yml. In tal caso, devi specificare la configurazione del DB in database.yml per i nostri ambienti su Heroku? O è ancora sicuro lasciarli fuori? Se è necessario specificare la configurazione per gli ambienti Heroku, sarà sufficiente quanto segue?
staging:
url: <%= ENV['DATABASE_URL'] %>
production:
url: <%= ENV['DATABASE_URL'] %>
Sono anche confuso sulla configurazione corretta per gli ambienti di sviluppo e test. Come accennato in precedenza, la prima configurazione mostrata ha quegli ambienti che utilizzano il DB di gestione temporanea su Heroku, anziché un DB locale.
This Heroku guide dice di esportare la variabile di ambiente DATABASE_URL per la connessione dell'app (una volta installato Postgres ed è possibile connettersi ad esso).
Supponendo di esportare l'ambiente DATABASE_URL var come specificato nell'articolo, come deve essere la configurazione per lo sviluppo e il test? Andiamo con la configurazione come mostrato nella prima guida, ad es.
default: &default
adapter: postgresql
encoding: unicode
pool: 5
timeout: 5000
development:
<<: *default
database: app_name_development
test:
<<: *default
database: app_name_test
o non usiamo una configurazione come mostrato in this Heroku guide (che utilizza host e username)
development:
adapter: postgresql
host: localhost
username: user
database: app-dev
Update 1: Ecco quello che ora so. Una configurazione di staging e produzione non è necessaria in config/database.yml se si distribuisce su Heroku, indipendentemente dalla versione di Rails. Prima della 4.2, Heroku generava il proprio file database.yml in base al valore della variabile di ambiente DATABASE_URL, sovrascrivendo il file di configurazione (se esistente). Dal momento che Rails 4.2, la tua app utilizzerà direttamente la variabile di ambiente DATABASE_URL (ignorando il file database.yml), quindi Heroku non ha bisogno (e non lo farà) di generare un file di configurazione.
Ho anche capito perché i miei ambienti di sviluppo e test utilizzavano il DB di staging remoto dall'app Heroku invece dei DB locali specificati nella loro configurazione database.yml.Era perché il mio file locale .env per lo sviluppo si basa sul mio file di gestione temporanea .env che contiene variabili di ambiente per la connessione al database come DATABASE_URL. Poichéera presente nel file di sviluppo .env, l'app Rails 4.2 lo utilizzava e quindi si connetteva al DB di gestione temporanea. Per risolvere il problema, ho rimosso quelle variabili di ambiente dal file di sviluppo .env e creato i DB locali (e ho eseguito le migrazioni) con bundle exec rake db:setup.
Update 2: Questa sezione delle Guide Rails va in maggiori dettagli su come configurare il DB, la pena di leggere: http://guides.rubyonrails.org/configuring.html#configuring-a-database
Simone, si tratta di una buona pratica in questo momento (stesso stack + server di Puma) per mettere 'piscina: <% = ENV [' MAX_THREADS '] || 5%> 'all'opzione di produzione? Il mio database.yml è gitignored al momento, ma per i server con thread heroku suggerisce di impostare il valore del pool per essere uguale a MAX_THREADS nel file database.yml. Sto facendo questa domanda per assicurarmi che non faccia nulla di stupido e perché il fraseggio dei documenti di heroku suona contraddittorio quando si tratta di database.yml. –