Play 2.0で環境ごとに異なるデータベースを設定するにはどうすればよいですか？

Question

私はPlayアプリケーションがテスト、ローカル、およびプロダクション（プロダクションはHeroku）環境で異なるデータベースを使用したいと思っています。 application.confで

私が持っている：

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} 

は、これが動作するようには思えません。私はこのことについていくつか質問してい

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

：：私はplay testまたはplay run、 すべてのDBへのアクセスに失敗したを実行すると、一般的に

• を、私は、データベースの構成方法について少し困惑していますプレー中の ：プレーンなのはdb,db.[DBNAME]、db. [DBNAME].urlのように見えますが、チュートリアルの違いによって、 の中からさまざまな選択肢があります。特定の表現がうまくいくように見えます（例：db.default.url = "jdbc:..."は、オブジェクトが必要な場所に文字列が入力されたというエラーで失敗します）。

• 私が見てきた他の人は、私は、それぞれがapplication.confが含まれ、別prod.conf、dev.confとtest.confファイルを作成し、DB固有の設定が含まれていることを示唆しています。しかしその場合、Playコンソールからtestを実行したときに使用するデータベースを指定するにはどうすればよいですか？

• %envの構文はPlay 2で動作するはずですか？

• play testで使用する環境を指定する正しい方法は何ですか？

Answer 1

プレイ2では、異なる設定環境はありません。代わりに、conf/application.confファイルの設定パラメータを設定または上書きするだけです。参照、例えば、HerokuのためProcfileについて

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

：

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

あなたはまた、別の設定ファイルを使用するように再生伝えることができます：
のように、それは、playコマンドライン上で行うための一つの方法プレイドキュメントで https://github.com/jamesward/play2bars/blob/scala-anorm/Procfile

詳細：
http://www.playframework.org/documentation/2.0/Configuration

Answer 2

設定値を読み込んだときにPlay.isTestをチェックし、読み込んだプロパティの先頭に 'test'を付けると、実際にPlay 2の設定値命名方法をPlay 2でも使用できます。ここで切り取られます：

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 = ...) 

および関連する設定の抜粋：

今

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

あなたがあなたのE2Eテストスイートを実行すると、任意のシステムプロパティの設定を覚えておく必要はありません、とあなたが誤っていないだろうprodデータベースに接続します。

test.の値を別々のファイルに置くこともできます。別のファイルに入れておけば、私が思うとメイン設定ファイルの最後にインクルードします。

Answer 3

少なくともPlay 2.1.1では、環境変数が設定されている場合、環境変数で設定値を上書きする可能性があります。 （詳細はを参照してください：http://www.playframework.com/documentation/2.1.1/ProductionConfiguration）

つまり、あなたのconf/application.confで次のように設定することができます。デフォルトあたり

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

を環境変数DATABASE_URL_DBはそれのための値を定義しない限り、それは定義されたJDBC-URLが使用されます。 したがって、環境変数を定義した設定では、開発データベースを設定します。

しかし、注意してください、あなたが引用符で囲まれた文字列内で、あなたの変数の参照を置く場合、この置換は動作しません：

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

代わりに、ちょうど例えば、置換するセクションをUNQUOTE。この例では

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

環境変数ENV_DATABASE_HOSTが設定されていない場合は、localhostがデフォルトで使用されます。 （詳細に関しては：https://www.playframework.com/documentation/2.5.x/ConfigFile#substitutions）

Answer 4

onLoadConfigグローバル/ GlobalSettings方法をオーバーライドして、そこからあなたは、以下のような一般的な設定と、特定の環境の構成でセットアップアプリケーションの設定をすることができますすることで、別のアプローチがあります...

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 

サンプル実装ではhttp://bit.ly/1AiZvX5を確認できます。

これが役に立ちます。オフトピック

Answer 5

いますが、12-因子アプリをたどるならば、環境にちなんで名付けられた別の構成を持つことは悪いです：

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

ソース：http://12factor.net/config