Jak skonfigurować różne bazy danych dla środowiska w wersji Play 2.0?

Question

Chciałbym, aby moja aplikacja Play korzystała z różnych baz danych dla środowisk testowych, lokalnych i produkcyjnych (produkcja to Heroku).

W application.conf mam:

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} 

nie wydają się działać. Kiedy uruchamiam play test lub play run, All Access DB nie powiedzie się z:

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

Mam kilka pytań na ten temat:

• Generalnie, jestem trochę mylić o tym, jak bazy danych są skonfigurowane w Play: wygląda na to, że są zwykłe db, db.[DBNAME] i db. [DBNAME].url, a różne tutoriale dokonują różnych wyborów spośród tych . Niektóre wyrażenia, które wyglądają, jakby powinny działać (np. db.default.url = "jdbc:...", nie powiodły się z błędem, że podano ciąg znaków, gdy obiekt był oczekiwany).

• widziałem inni sugerują, że tworzę osobne prod.conf, dev.conf i test.conf pliki z których każda zawiera application.conf a następnie zawierać DB-specyficzną konfigurację. Ale w takim przypadku, w jaki sposób określić, jakiej bazy danych użyć po uruchomieniu test z konsoli Play?

• Czy składnia %env ma działać w Play 2?

• Jaki jest prawidłowy sposób określenia środowiska, z którego można korzystać play test?

Answer 1

W grze 2 nie ma różnych środowisk konfiguracyjnych. Zamiast tego wystarczy ustawić lub przesłonić parametry konfiguracyjne w pliku conf/application.conf. Jednym ze sposobów, aby to zrobić jest w linii poleceń play, jak:

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

Można również powiedzieć Play użyć innego pliku config:

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

Dla przykładu Procfile dla Heroku patrz:
https://github.com/jamesward/play2bars/blob/scala-anorm/Procfile

Więcej szczegółów w Dokumentach Play:
http://www.playframework.org/documentation/2.0/Configuration

Answer 2

Wciąż możesz używać metody nazewnictwa wartości 1.0 w Play 2, jeśli podczas ładowania wartości konfiguracyjnych sprawdź, czy jest to Play.isTest, a następnie przedrostkiem właściwości ładujesz za pomocą "testu". Oto 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 = ...) 

i odnośny fragment config:

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" 
... 

Teraz nie trzeba pamiętać ustawiania żadnych właściwości systemu po uruchomieniu zestawu testowego e2e, i nie będzie przypadkowo połączyć się z bazą danych prod.

Przypuszczam, że można opcjonalnie umieścić wartości test. w osobnym pliku, który następnie zostanie umieszczony na końcu głównego pliku konfiguracyjnego.

Answer 3

Przynajmniej w Play 2.1.1 możliwe jest nadpisanie wartości konfiguracyjnych za pomocą zmiennych środowiskowych, jeśli są ustawione. (Po szczegóły patrz: http://www.playframework.com/documentation/2.1.1/ProductionConfiguration)

Więc można ustawić następujące w swojej conf/application.conf:

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

domyślnie będzie korzystał z JDBC URL zdefiniowany chyba że zmienna DATABASE_URL_DB definiuje wartość dla niego. Po prostu ustawiasz bazę danych programowania w konfiguracji i produkcji lub etapach, które definiują zmienną środowiskową.

Ale uwaga, to podstawienie nie działa, jeśli umieścić zmienną odniesienia wewnątrz cudzysłowami:

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

Zamiast tego właśnie cytatu sekcję być podstawione, na przykład.

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

W tym przykładzie localhost będzie używana domyślnie, jeśli zmienna środowiskowa ENV_DATABASE_HOST nie jest ustawiony. (Po szczegóły patrz: https://www.playframework.com/documentation/2.5.x/ConfigFile#substitutions)

Answer 4

Nie ma innego podejścia, które ma zastąpić Globalna/GlobalSettings metoda onLoadConfig a stamtąd można konfiguracji aplikacji setup z generycznego config i specyficznej konfiguracji środowiska jak poniżej ...

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 

Możesz sprawdzić http://bit.ly/1AiZvX5 dla mojej przykładowej realizacji.

Mam nadzieję, że to pomoże.

Answer 5

ale jeśli po 12-factor-app następnie posiadające oddzielne konfiguracje nazwanych po środowiskach jest złe Off-topic:

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

źródło: http://12factor.net/config