Reputation: 323
(Never write software when you are very tired. Otherwise you ask very nice people on the internet to answer very obvious questions, that you would not ask, if you were not tired, because the principle problem is ... trivial. lol. So, in this case, I had neglected to uniquely rename the connection properties of the alternate database. Sigh....)
PROBLEM: I can't make Laravel recognize a request for a different connection (database).
As far as I know, I've correctly configured .ENV, config/database.php, config/app.php correctly, and added $connection=myconnection to my models.
But no matter what I do Laravel/Eloquent/Doctrine Ignores all attempts to have some models use the default (common) database, and others use the multi-tenant databases.
Let's distinguish between a physical server, a database server instance running on that server, and a database within that instance, and multi-tenancy within that database.
I should be able to use any of these configurations by modifying the connection at runtime:
And I suspect that the lack of documentation, yet the inclusion of the eloquent/model feature "$connection=connection_configuration" means there is a fairly obvious solution that I don't intuit. (and I don't have a few free days to delve into the source and figure out what's going on there.)
Thanks for any help. -Cheers
===ENV FILE===
DB_CONNECTION=crunch
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=crunch
DB_USERNAME=myapp
DB_PASSWORD=Nonsense!Talk
DB_CONNECTION=munchdata
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=munchdata
DB_USERNAME=myapp
DB_PASSWORD=Nonsense!Talk
===CONFIG/DATABASE.PHP===
'connections' => [
'crunch' => [
'driver' => 'mysql',
'host' => env('DB_HOST', '127.0.0.1'),
'port' => env('DB_PORT', '3306'),
'database' => env('DB_DATABASE', 'crunch'),
'username' => env('DB_USERNAME', 'crunch'),
'password' => env('DB_PASSWORD', 'Nonsense!Talk'),
'unix_socket' => env('DB_SOCKET', ''),
'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',
'prefix' => '',
'strict' => true,
'engine' => null,
'sticky' => true,
],
'munchdata' => [
'driver' => 'mysql',
'host' => env('DB_HOST', '127.0.0.1'),
'port' => env('DB_PORT', '3306'),
'database' => env('DB_DATABASE', 'munchdata'),
'username' => env('DB_USERNAME', 'munchdata'),
'password' => env('DB_PASSWORD', 'Nonsense!Talk'),
'unix_socket' => env('DB_SOCKET', ''),
'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',
'prefix' => '',
'strict' => true,
'engine' => null,
'sticky' => true,
],
],
===CONFIG/APP.PHP FILE===
'default' => env('DB_CONNECTION', 'crunch'),
// Default connections work fine
===A MODEL===
class EntityType extends BaseModel
{
use SoftDeletes;
public $connection = 'munchdata';
public $table = 'entity_type';
( ... )
}
// Ignores $connection
===CONSOLE===
>>> DB::connection('crunch')->getDatabaseName()
=> "crunch"
// Uses default connection
>>> DB::connection('munchdata')->getDatabaseName()
=> "crunch"
>>>
// Ignores connection
$result = DB::connection('munchdata')->select('select * from entity_type');
// Ignores the connection, and returns data from default db
$result = DB::connection('munchdata')->select('select munchdata.entity_type.* from munchdata.entity_type');
// Ignores the connection, but returns the right data anyway....
Upvotes: 1
Views: 870
Reputation: 323
The values in the .ENV file must be unique, because the value "DB_CONNECTION=myDatabaseName" is not an array keyed from "myDatabaseName", but a 'dumb' string value. Meaning all entries in .ENV files must be uniquely named.
In other words, the .ENV files work OPPOSITELY from the Config/App > Connection[] definitions. Which... doesn't make a lot of sense, and isn't necessary.
I'd assumed that .ENV file was brought into an array with myDatabaseName as the key, and that the "DB_*" strings were constants. This seems logical.
This is probably how it SHOULD work, but it is not how it DOES work.
I suppose that since I've seen many other people post questions because of similar suppositions, that either we should request the change, or that I should write a bit of code to allow for multiple configs using the same constants as keys.
SOLUTION:
(1) If you have a small number of relatively invariant databases, continue to use the .ENV file - and give each CONSTANT a different name.
(2) If you dynamically create new databases, use .ENV for your default (boot) database, and then:
Either (a) Use your default (boot) database to store the related database connection configurations and cache them - which exposes your connection data and forces you to replicate that data for new instances,
Or (b) Use the file system to store the related database configurations, and (c) cache them.
In my case I have N (a lot) of databases, and I prefer using the db and then replication (dump and load the table with connection info) rather than a file of unknown size with the chance of 'leaking' into the real world due to dev/IT error or malice...
Cheers
Upvotes: 1