Cómo configurar diferentes bases de datos por medio de Play 2.0?

Me gustaría que mi Juego aplicación para el uso de diferentes bases de datos de la prueba, la local y la producción (la producción es Heroku) ambientes.

En application.conf 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 ejecuto play test o play run,
todos los DB de access no puede con:

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

Tengo un par de preguntas acerca de esto:

En general, estoy un poco confundido acerca de cómo las bases de datos se configuran
en Juego: parece que hay llanura db, db.[DBNAME] y db. [DBNAME].url y diferentes tutoriales de tomar decisiones diferentes entre
los. Ciertas expresiones que parecen que deben trabajar (por ejemplo, db.default.url = "jdbc:..." fallar con un error que fue una cadena donde un objeto que se esperaba).
He visto que otras personas sugieren que puedo crear diferentes prod.conf, dev.conf y test.conf archivos, cada uno con application.conf y, a continuación, contienen DB-configuración específica. Pero en ese caso, ¿cómo puedo especificar qué base de datos para utilizar cuando ejecuto test desde el Juego de consola?
Es el %env sintaxis supone que funciona en la Play 2?
¿Cuál es la manera correcta para especificar un entorno para play test a utilizar?

InformationsquelleAutor Bill | 2012-04-30

5 Comentarios

21

En Play 2 no son diferentes de configuración de los ambientes. En lugar de que usted acaba de establecer o anular los parámetros de configuración en el conf/application.conf archivo. Una manera de hacerlo es en el play de la línea de comandos, como:
```
play -Ddb.default.driver=org.postgresql.Driver -Ddb.default.url=$DATABASE_URL ~run
```
También puede informar a Jugar a utilizar una configuración diferente de archivo:
```
play -Dconfig.file=conf/prod.conf ~run
```
Para un ejemplo Procfile para Heroku, ver:

https://github.com/jamesward/play2bars/blob/scala-anorm/Procfile

Más detalles en el Juego Docs:

http://www.playframework.org/documentation/2.0/Configuration
- Hmm, eso tiene sentido – así que los %prod consejos eran para Jugar 1.x? Gracias por los ejemplos. La verdad es que tengo el dev/prod problema de configuración trabajado en este punto. Mi pregunta es: ¿cómo hago para configurar el Juego en un entorno diferente al ejecutar el conjunto de pruebas?
- Sí, la %prod cosas es Jugar 1.x solamente. Usted debe ser capaz de hacer lo mismo al ejecutar las pruebas: play -Dsetting=foo ~test
- Eso es cierto, pero parece muy propenso a errores: si yo accudentally dejar fuera de la configuración de nombre de archivo, mi (potencialmente destructiva) de la suite de prueba se ejecute en contra de mi dev base de datos. No hay otra manera de hacer esto? El %prod enfoque del Juego 1 parece más que suficiente, no sé por qué no está disponible ya.
- Usted podría salir de la aplicación.conf esencialmente vacío y, a continuación, han dev.conf, de prueba.conf, y prod.conf archivos. Si los valores son comunes, entonces usted podría ponerlas en aplicación.conf y, a continuación, incluir la aplicación.conf en el otro conf de archivos.
InformationsquelleAutor James Ward
11

Al menos en el Juego 2.1.1 es, posiblemente, para invalidar la configuración de los valores con las variables de entorno, si se establecen. (Para más detalles ver: http://www.playframework.com/documentation/2.1.1/ProductionConfiguration)

Así que usted 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 utiliza el JDBC-URL definida, a menos que la variable de entorno DATABASE_URL_DB define un valor para ella.
Tan sólo tiene que configurar su base de datos de desarrollo en la configuración y para la producción o etapas de definir la variable de entorno.

Pero cuidado, esta sustitución NO funciona si pones la variable de referencia dentro de las cadenas entre comillas:
```
db.default.url="jdbc:${?DATABASE_URL_DB}"
```
Lugar, simplemente cierro la cita de la sección para 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 por defecto, se usará si la variable de entorno ENV_DATABASE_HOST no está configurado. (Para más detalles ver: https://www.playframework.com/documentation/2.5.x/ConfigFile#substitutions)
- Esa es una característica impresionante!
InformationsquelleAutor Marcus Schiesser
2

Usted puede todavía utilizar el Juego 1.0 config valor método de nomenclatura, en el Juego 2, si usted, cuando usted carga los valores de la configuración, compruebe si Play.isTest, y luego el prefijo de las propiedades que carga con ‘la prueba’.. He aquí una corta:
```
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 los relacionados con la config 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 la configuración de alguna de las propiedades del sistema al ejecutar su e2e de la suite de prueba, y no accidentalmente conectarse a la prod de la base de datos.

Supongo que opcionalmente se puede colocar el test. valores en un archivo independiente, que, a continuación, incluir al final de el archivo de configuración principal de pienso.

InformationsquelleAutor KajMagnus
0

Existe otro enfoque que es para anular Global /GlobalSettings método onLoadConfig y desde allí se puede configurar la configuración de la aplicación con el genérico de configuración y entorno específico de configuración, como el de abajo…
```
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 comprobar http://bit.ly/1AiZvX5 para mi ejemplo de aplicación.

Espero que esto ayude.

InformationsquelleAutor paullabis
0

Off-topic pero si sigues 12-factor-de la aplicación, a continuación, tener diferentes configuraciones de llamada después de entornos es malo:

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

InformationsquelleAutor ObjectiveTruth

5 Comentarios

Dejar respuesta Cancelar respuesta