¿Cómo configurar diferentes bases de datos por entorno en Play 2.0?

Question

Me gustaría que mi aplicación Play utilice diferentes bases de datos para entornos de prueba, locales y de producción (producción es Heroku).

En application.conf que tengo:

db.default.driver=org.postgresql.Driver 

%dev.db.default.url="jdbc:postgresql://localhost/foobar" 
%test.db.default.url="jdbc:postgresql://localhost/foobar-test" 
%prod.db.default.url=${DATABASE_URL} 

Esto no parece funcionar. Cuando corro play test o play run, todo el acceso DB falla con:

Configuration error [Missing configuration [db.default.url]] (Configuration.scala:258) 

Tengo algunas preguntas acerca de este:

• En general, estoy un poco confundido acerca de cómo se configuran las bases de datos en Play: parece que hay db llana, db.[DBNAME] y db. [DBNAME].url y diferentes tutoriales hacen diferentes elecciones entre esos. Ciertas expresiones que parecen que deberían funcionar (por ejemplo, db.default.url = "jdbc:..." fallan con un error de que se proporcionó una cadena donde se esperaba un objeto).

• que he visto otras personas sugieren que creo separados prod.conf, dev.conf y test.conf archivos que incluyen cada uno application.conf y contendrá entonces DB de configuración específica. Pero en ese caso, ¿cómo especifico qué base de datos usar cuando ejecuto test desde la consola Play?

• ¿Se supone que la sintaxis %env funciona en Play 2?

• ¿Cuál es la forma correcta de especificar un entorno para el uso de play test?

Answer 1

En Play 2 no hay entornos de configuración diferentes. En su lugar, simplemente establece o anula los parámetros de configuración en el archivo conf/application.conf. Una forma de hacerlo es en la línea play comando, como:

play -Ddb.default.driver=org.postgresql.Driver -Ddb.default.url=$DATABASE_URL ~run 

También puede decirle Juego utilizar un archivo de configuración diferente:

play -Dconfig.file=conf/prod.conf ~run 

Por ejemplo Procfile de Heroku, vea:
https://github.com/jamesward/play2bars/blob/scala-anorm/Procfile

Más detalles en la documentación de juego:
http://www.playframework.org/documentation/2.0/Configuration

Answer 2

En realidad, puede seguir utilizando el método de nomenclatura del valor de configuración de Play 1.0 en Play 2 si, al cargar valores de configuración, comprueba si Play.isTest y, a continuación, escribe las propiedades que carga con 'prueba'. He aquí una snipped:

def configPrefix = if (play.api.Play.isTest) "test." else "" 

def configStr(path: String) = 
    Play.configuration.getString(configPrefix + path) getOrElse 
    die(s"Config value missing: $configPrefix$path") 

new RelDb(
    server = configStr("pgsql.server"), 
    port = configStr("pgsql.port"), 
    database = configStr("pgsql.database"), 
    user = ..., 
    password = ...) 

Y la configuración relacionada fragmento:

pgsql.server="192.168.0.123" 
pgsql.port="5432" 
pgsql.database="prod" 
... 

test.pgsql.server="192.168.0.123" 
test.pgsql.port="5432" 
test.pgsql.database="test" 
... 

Ahora usted no necesita recordar el establecimiento de las propiedades del sistema cuando se ejecuta el conjunto de pruebas E2E, y no accidentalmente conectarse a la base de datos prod.

Supongo que puede colocar opcionalmente los valores test. en un archivo separado, que luego incluiría al final del archivo de configuración principal, creo.

Answer 3

Al menos en Play 2.1.1 es posible anular los valores de configuración con variables de entorno, si están configuradas. (Para más detalles ver: http://www.playframework.com/documentation/2.1.1/ProductionConfiguration)

Así se puede establecer lo siguiente en su conf/application.conf:

db.default.url="jdbc:mysql://localhost:3306/my-db-name" 
db.default.url=${?DATABASE_URL_DB} 

por defecto se utilizará la URL de JDBC-definido a menos que la variable de entorno DATABASE_URL_DB define un valor para ella. Así que simplemente establece su base de datos de desarrollo en la configuración y para la producción o las etapas define la variable de entorno.

Pero cuidado, esta sustitución no funciona si usted pone su referencia variable dentro de cadenas entre comillas:

db.default.url="jdbc:${?DATABASE_URL_DB}" 

En cambio, sólo Unquote la sección que ser sustituido, por ejemplo.

database_host = "localhost" 
database_host = ${?ENV_DATABASE_HOST} 
db.default.url="jdbc:mysql://"${?database_host}":3306/my-db-name" 

En este ejemplo, localhost será utilizado por defecto si la variable de entorno ENV_DATABASE_HOST no está establecido. (Para más detalles ver: https://www.playframework.com/documentation/2.5.x/ConfigFile#substitutions)

Answer 4

Hay otro enfoque que consiste en reemplazar el método/GlobalSettings Global onLoadConfig y desde allí se puede configuración de la aplicación de configuración con la configuración genérica y específica configuración del entorno, como a continuación ...

conf/application.conf --> configurations common for all environment 
conf/dev/application.conf --> configurations for development environment 
conf/test/application.conf --> configurations for testing environment 

conf/prod/application.conf --> configurations for production environment 

Puede consultar http://bit.ly/1AiZvX5 para la implementación de mi muestra.

Espero que esto ayude.

Answer 5

pero si sigue 12-factor de la aplicación y luego tener configuraciones separadas con nombres de ambientes es malo fuera de tema:

Another aspect of config management is grouping. Sometimes apps batch config into named groups (often called “environments”) named after specific deploys, such as the development, test, and production environments in Rails. This method does not scale cleanly: as more deploys of the app are created, new environment names are necessary, such as staging or qa. As the project grows further, developers may add their own special environments like joes-staging, resulting in a combinatorial explosion of config which makes managing deploys of the app very brittle

fuente: http://12factor.net/config