Closed atrauzzi closed 9 years ago
Something along these lines:
'mysql' => [
'driver' => 'mysql',
'host' => env('DB_SOCKET') ? null : env('DB_HOST', 'localhost'),
'unix_socket' => env('DB_SOCKET'),
'database' => env('DB_DATABASE', 'laravel'),
'username' => env('DB_USERNAME', 'root'),
'password' => env('DB_PASSWORD', ''),
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
'strict' => false,
],
Let me think about this one. I'll also need some time for usability testing.
It's a pretty minor change and I've got it in a project I'm going to be deploying next week. I'll let you know if I encounter any snags. I can't imagine I will though given that both just use the regular MySQL behaviours.
Thanks. I fully agree it should be a very simple change. Still the configuration has to be tested with GAE and local database servers while changing the environment variables only (switching the .env
files).
I would prefer to stick with a separate configuration CloudSQL. It requires minimum of configuration file changes and still allows quick switching between the configurations. But I would like to replace CLOUD_SQL_
prefix with DB_
(the regular one.)
That sounds like a good middle-ground. And more or less is the same as what I suggested -- just have to make sure people use that driver in the right environments.
Incorporated in version 1.4.2.
I've been tidying up my project, and I'm wondering if there's any reason to maintain a separate database config set for Cloud SQL.
My reasoning in this case would be because we're able to influence the runtime via
.env
. At which point my instinct is to trim out thecloudsql
entries, and just recycle themysql
config for both local and live environments.Might be nice to have one less thing to have to pivot when deploying, and heck -- it's less documentation at that point too! ;)