web-dev-qa-db-ja.com

奇妙なLaravel 5間違ったデータベース名を使用したキャッシュ

ローカル開発マシン上にすべてAngularJSアプリを提供している2つのLaravel APIがあります。AngularページがPOSTを呼び出すと、奇妙な問題が発生します間違ったデータベース名を使用しているように見える両方のAPI（他のLaravelのインスタンスのデータベースを使用しています）Laravelは、Table database.tableが見つかりませんという例外をスローします。データベースは正しくありませんデータベース。Postmanを使用して各APIを呼び出してみましたが、正常に機能します。どちらのプロジェクトにも他のデータベースについての言及はないと確信しています。

私には、これはキャッシュの問題のように見えます。envファイルがキャッシュされ、何らかの理由で2つのLaravelサーバー間で共有される可能性があります。両方のLaravelアプリはApacheでホストされています。php artisan config:clearを呼び出して、.htaccessファイルに適切なヘッダーを設定してキャッシュを防止しようとしましたが、どちらも機能しませんでした。複数のブラウザーで試し、キャッシュをクリアしました。 、それでも同じエラー。

.envファイルを使用して、開発サーバーに固有の構成を設定できるようにしたいので、config/database.phpにデータベースの資格情報をハードコーディングしたくありません。問題になる可能性のあるアイデアはありますか？

両方のdatabase.phpファイルは次のようになります。

'mysql' => [
'driver'    => 'mysql',
'Host'      => env('DB_Host'),
'database'  => env('DB_DATABASE'),
'username'  => env('DB_USERNAME'),
'password'  => env('DB_PASSWORD'),
'charset'   => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix'    => '',
'strict'    => false, 
],

一意の設定が.envに保存されている場所

phpmysqlangularjscachinglaravel-5.1
9
Gabriel

私のために働いたのは、これらのコマンドを実行することによって、Laravel設定の束をクリアすることでした：

php artisan config:clear
php artisan cache:clear
php artisan route:clear
php artisan view:clear
php artisan optimize

どのコマンドがそれを実行したかはわかりませんが、Laravelは、データベース構成用に.envファイルを正しく認識/読み取ります。

12
Denis Priebe

私のように、誰かがまだこの問題を抱えている場合。次に、次のコマンドを使用できます。

php artisan config:cache

前述のように環境を設定した後 ここ 。

問題は、チームメンバーが製品の環境ファイルで何かを変更するたびに、このコマンドが確実に実行されることです。

8
SuperNOVA

私は同じ問題を経験しました、そして私の場合、それは https://github.com/vlucasのtoddbcによって報告された問題によって引き起こされました/ phpdotenv/issues/76 。

Laravelは_vlucas/phpdotenv_に依存しており、PHPのputenv()を使用して_.env_ファイルから値を追加し、アプリケーションからアクセスできるようにします。しかしながら、

putenv()およびgetenv()は、再入可能またはスレッドセーフである必要はありません。これが意味するのは、2つのスレッドが（異なるコア上で、または関数の途中のコンテキストスイッチから）それらを同時に呼び出すと、悪いことが起こる可能性があるということです。

したがって、PHP（私の場合は異なるアプリケーションから）の2つのインスタンスは、同時要求中に互いに属する環境変数を読み取ることができました。

vlucasが問題レポートへの返信で役立つように説明しているように、これは予想される動作であり、解決策はWebサーバー構成ファイルで環境変数を定義することです。

私のために働いたのは、_DB_Host_、_DB_DATABASE_、_DB_USERNAME_、_DB_PASSWORD_行を_.env_ファイルから削除し、Apache仮想ホスト構成ブロックに以下を追加することでした。 ：

_SetEnv DB_Host db_Host
SetEnv DB_DATABASE db_name
SetEnv DB_USERNAME db_user
SetEnv DB_PASSWORD db_pass
_

（設定を変更した後、Apacheを再起動することを忘れないでください）

Webルートに1つのLaravelアプリがあり、ApacheAliasディレクティブを使用してリクエストをにルーティングするサブディレクトリに追加のLaravelアプリがインストールされている場合適切なアプリケーションでは、[〜＃〜]両方[〜＃〜]のデータベース資格情報のセットにSetEnvIfを使用する必要があります。そう：

_# Laravel app 1 in web root
SetEnvIf Host ".*" DB_Host=db1_Host
SetEnvIf Host ".*" DB_DATABASE=db1_name
SetEnvIf Host ".*" DB_USERNAME=db1_user
SetEnvIf Host ".*" DB_PASSWORD=db1_pass

# Laravel app 2 in subdirectory "/subdir"
SetEnvIf Request_URI ^/subdir DB_Host=db2_Host
SetEnvIf Request_URI ^/subdir DB_DATABASE=db2_name
SetEnvIf Request_URI ^/subdir DB_USERNAME=db2_user
SetEnvIf Request_URI ^/subdir DB_PASSWORD=db2_pass
_

（SetEnvとSetEnvIfの組み合わせを使用できない理由の説明については、 https://staff.washington.edu/fmf/2013/04/24を参照してください）/using-setenv-and-setenvif-together-in-Apache / ）

このソリューションの良いところは（それがうまくいく場合）、問題が顕在化する環境でのみ実装する必要があることです。つまり、ローカルの開発環境にのみ影響する場合は、本番サーバーで何も変更する必要はありません。

7
Mark Leong

php artisan serveでサーバーを再起動すると、同じ問題が修正されました

4
Bizboss

古い質問ですが、他の誰かがこれが彼らに起こっていることに気付いた場合に備えて（私に起こったように）、私の簡単な解決策は、プロジェクトの1つで.env変数の名前を変更することでした：

DB_X_Host="localhost"
DB_X_DATABASE="other_project"
DB_X_USERNAME="Homestead"
DB_X_PASSWORD="secret"
DB_X_PORT="3306"

次に、config\database.phpの変数を次のように変更します。

'mysql' => [
        'driver' => 'mysql',
        'Host' => env('DB_X_Host', '127.0.0.1'),
        'port' => env('DB_X_PORT', '3306'),
        'database' => env('DB_X_DATABASE', 'forge'),
        'username' => env('DB_X_USERNAME', 'forge'),
        'password' => env('DB_X_PASSWORD', ''),
        'charset' => 'utf8mb4',
        'collation' => 'utf8mb4_unicode_ci',
        'prefix' => '',
        'strict' => true,
        'engine' => null,
    ]

これで、マークの応答に詳細な相互汚染が発生することはありません。

2
ssssteve

これは私のために働いた：

php artisan config:cache
0
Toufic Ahemmed

次のコマンドを入力するだけです。

php artisan config:cache
0
Naveen007

私はまったく同じ問題を抱えています。 1つのWebページがlaravelからの異なるデータセットで5つのjson応答を要求し、それらの正確な要求を独自のブラウザーで再ロードした場合でも、要求の約半分が「不正なデータベース」エラーで爆撃されますタブは正常に動作します。LaravelバグはApacheからの同時Webリクエストの処理に関係しているようです。

とにかく、私の回避策は、config\database.phpファイル内のすべての接続のホスト、データベース、ユーザー名、およびパスワードをハードコーディングすることでしたが、jsonリクエストはもう爆撃しません。ただし、パスワードをソース管理にハードコーディングし、複数の環境を処理する必要があるのは面倒です。基本的に、.envファイルが存在する前の暗黒時代に戻ります。

0
David Carr