(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:
Single app/db server, single app, single database, with multi-tenants
Single app/db server, single app, multiple databases, with multi-tenants
Single app/db server, single app, multiple database instances, each with multiple databases, with multi-tenants
Single app server, multiple database servers, multiple databases instances, each with multi-tennants.
Multiple app servers, multiple database servers, multiple databases instances, each with multi-tennants.
And any combination thereof.
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....
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
Related
I have set up read/write database connections in laravel for database optimization. I would like to know that if our read server does not respond, then all request should go the primary database write server. is that possible in laravel?
Here is my database.php config file
'mysql' => [
'read' => [
'host' => '192.168.1.1',
],
'write' => [
'host' => '192.168.1.2'
],
'driver' => 'mysql',
'host' => env('DB_HOST', 'localhost'),
'database' => env('DB_DATABASE', 'laravel'),
'username' => env('DB_USERNAME', 'root'),
'password' => env('DB_PASSWORD', 'root'),
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
'strict' => false,
],
AFAIK we can't achieve without extending Laravel core. Basically I believe this kind of problem should be resolved by infrastructure configurations, not by application.
For example, if you are using AWS Aurora, you can use reader(readonly) endpoint.
【新機能】Amazon Aurora で読み込みエンドポイントが利用可能になりました | Developers.IO (Japanese)
If your cluster's writer endpoint is cluster1.cluster-xxxxx.us-east-1.rds.amazonaws.com, the reader one will be available with suffix *-ro: cluster1.cluster-ro-xxxxx.us-east-1.rds.amazonaws.com.
Reader endpoint behaves exactly as you want. Normally, loads are balanced by round-robin scheduling. When a reader crashes, it will be automatically excluded from the network. When a writer crashes, one of the readers is automatically promoted to a writer. It's a very cool feature.
In Laravel 4, I could specify the testing database through the config/testing/database file.
This file has, of course, been removed from Laravel 5 just to make things pointlessly more difficult.
So, how do I set up a MySQL test database in Laravel 5.
I do not want to use a SQLite database.
I would suggest some code but there isn't anything on SO or through Google that even attempts to answer this question.
Thank you.
If you check out the documentation Testing - Test Environment this mentions you set environment variables in the phpunit.xml
So for example you would add
<phpunit>
<php>
<env name="DB_CONNECTION" value="sqlite"/>
</php>
</phpunit>
to set the DB_CONNECTION I know you said you don't want to use SQLite but this is just an example you can set any of the values you would normally set in your .env file.
See Using Environment Variables to Add Flexibility to PHPUnit Tests for some more details on the use of environmental variables with PHPUnit.
You could go with the following approach:
Set your default databse connection to 'testing' when the app environment is also 'testing' in your database.php file:
'default' => app()->environment() == "testing" ?
env('DB_CONNECTION_TESTING', 'testing') :
env('DB_CONNECTION', 'mysql'),
Then also in your database.php file add the testing connection:
'testing' => [
'driver' => 'mysql',
'host' => env('DB_HOST_TESTING', 'localhost'),
'database' => env('DB_DATABASE_TESTING', 'forge'),
'username' => env('DB_USERNAME_TESTING', 'forge'),
'password' => env('DB_PASSWORD_TESTING', ''),
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
'strict' => false,
],
In your .env file you have to add the corresponding lines:
DB_HOST_TESTING=localhost
DB_DATABASE_TESTING=database_testing
DB_USERNAME_TESTING=username_testing
DB_PASSWORD_TESTING=password_testing
So every time the app environment is testing ( which is the case in phpunit tests for example ) your application uses the testing database connection.
Of course you could also modify the phpunit.xml file like mentioned in the answer of Mark Davidson.
Getting this error message RANDOMLY while nav'ing to my view:
QueryException in Connection.php line 636:SQLSTATE[42S02]: Base table or view not found: 1146 Table 'salesspacetv.devices' doesn't exist (SQL: select count(*) as aggregate from devices inner join statustypes on devices.status = statustypes.num inner join aggservers on devices.aggserver_num = aggservers.num left join tickets on devices.id = tickets.device_id group by devices.id) in Connection.php line 636
My server uses multiple virtual hosts, defined in c:\apache24\conf\extra\httpd-vhosts.conf.
"c1.[ourcompanyname].net" is the name of the site whose view I'm nav'ing to.
"salesspacetv.[ourcompanyname].net" is another virtual host (running laravel) on our server.
The word "salesspacetv" absolutely does not exist anywhere in c1's code.
"devices" IS a table used by the c1 site, and there is no "devices" table used by the salesspacetv site.
It seems like laravel's base code is making use somewhere of what it thinks is the subdomain name and that Apache (fyi... running on Windows, on this server) is somehow not getting the correct subdomain name to laravel.
Again, this is a random error. If I simply refresh the page, the error goes away. Also note, whether important or not, that this view is using pagination. I don't imagine that has any importance, but I figured it was worth mentioning.
The databases are MySQL databases.
Lastly, the c1 virtual host definition does actually appear before the salesspacetv virtual host definition in httpd-vhosts.conf.
Thanks.
I believe I ran into this error in the past when I was dealing with multiple projects in my local environment.
Let me get this straight, you are using 1 project then whenever it is involving a database table call it sometimes references to a table or column name that the current project does not contain but contains in another project?
If that is what's happening to you, how I fixed it on my end was name your database environments (.env file) different per project.
#1 .env Method
.env
Project 1:
DB_PROJECT1_HOST=0.0.0.0
DB_PROJECT1_DATABASE=dbname
DB_PROJECT1_USERNAME=dbuser
DB_PROJECT1_PASSWORD=dbpass
Project 2:
DB_PROJECT2_HOST=0.0.0.0
DB_PROJECT2_DATABASE=dbname
DB_PROJECT2_USERNAME=dbuser
DB_PROJECT2_PASSWORD=dbpass
app\config\database.php
Project 1:
'mysql' => [
'driver' => 'mysql',
'host' => env('DB_PROJECT1_HOST'),
'database' => env('DB_PROJECT1_DATABASE'),
'username' => env('DB_PROJECT1_USERNAME'),
'password' => env('DB_PROJECT1_PASSWORD'),
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
'strict' => false,
],
Project 2:
'mysql' => [
'driver' => 'mysql',
'host' => env('DB_PROJECT2_HOST'),
'database' => env('DB_PROJECT2_DATABASE'),
'username' => env('DB_PROJECT2_USERNAME'),
'password' => env('DB_PROJECT2_PASSWORD'),
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
'strict' => false,
],
Hopefully this is the same issue happening to you so you can quickly test this and see if it applies to you.
#2 Alternative (hardcode method suggested by Tezla):
You may also edit the database configuration file (app\config\database.php) and hardcode the database information directly to avoid configuration leaks:
'mysql' => [
'driver' => 'mysql',
'host' => '0.0.0.0',
'database' => 'dbname',
'username' => 'dbuser',
'password' => 'dbpass',
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
'strict' => false,
]
'default' => env('DB_CONNECTION', 'mysql'),
'connections' => [
'sqlite' => [
'driver' => 'sqlite',
'database' => storage_path('database.sqlite'),
'prefix' => '',
],
**JUST CHANGED THE CODE FOR LOCALHOST AND CHANNGED THE NAME TO ROOT AND SET THE PASSWORD OF PHPMYADMIN . **
**WHEN WRITTING THE COMMAND IN XAMPP SHELL ((Php artisan migrate:install)) **
'mysql' => [
'driver' => 'mysql',
'host' => env('DB_HOST', 'localhost'),
'database' => env('DB_DATABASE', 'laravel'),
'username' => env('DB_USERNAME', 'root'),
'password' => env('DB_PASSWORD', 'password'),
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
'strict' => false,
],
'pgsql' => [
'driver' => 'pgsql',
'host' => env('DB_HOST', 'localhost'),
'database' => env('DB_DATABASE', 'forge'),
'username' => env('DB_USERNAME', 'password'),
'password' => env('DB_PASSWORD', ''),
'charset' => 'utf8',
'prefix' => '',
'schema' => 'public',
],
'sqlsrv' => [
'driver' => 'sqlsrv',
'host' => env('DB_HOST', 'localhost'),
'database' => env('DB_DATABASE', 'forge'),
'username' => env('DB_USERNAME', 'password'),
'password' => env('DB_PASSWORD', ''),
'charset' => 'utf8',
'prefix' => '',
],
],
/*
|--------------------------------------------------------------------------
| Migration Repository Table
|--------------------------------------------------------------------------
|
| This table keeps track of all the migrations that have already run for
| your application. Using this information, we can determine which of
| the migrations on disk haven't actually been run in the database.
|
*/
'migrations' => 'migrations',
/*
|--------------------------------------------------------------------------
| Redis Databases
|--------------------------------------------------------------------------
|
| Redis is an open source, fast, and advanced key-value store that also
| provides a richer set of commands than a typical key-value systems
| such as APC or Memcached. Laravel makes it easy to dig right in.
|
*/
'redis' => [
'cluster' => false,
'default' => [
'host' => '127.0.0.1',
'port' => 6379,
'database' => 0,
],
],
it is showing error SQLSTATE[HY000] [1045] Access denied for user 'root'#'localhost' (using password: YES)
By default laravel assumes that you will want to have different configurations for different environments. E.g. in a testing environment, you might wish to have a different username and password and in a production environment different. Since laravel has so many configuration files, it quickly becomes a nightmare to manage all those. Hence laravel makes use of PHP's environment variables.
See the docs here.
What is basically says is that if you wish to use the "environment" variables, which laravel uses by default, you have to place all your configurations in the env() method as already mentioned.
If you do not wish to do this, e.g. for simple projects, simply remove the env from your code, like this.
'mysql' => [
'driver' => 'mysql',
'host' => 'localhost',
'database' => 'laravel',
'username' => 'root',
'password' => 'password',
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
'strict' => false,
],
Note that you can mix and match. i.e you can have some of the variables in env and some stand-alone.
So why use env at all?
Lets say your application has 100 testers all placed in different locations. In laravel you have to code approximately 8-10 configuration files. Also you need to version-control those files. So you have two problems at hand:
You do not wish to send all 100 users the same credentials. Also they might use different database, cache server, etc which means that they will have different configurations. So every user has to maintain those 8-10 configuration files by hand.
You do not wish to send these configuration files to version control. Because if you do, whole world will know your API secrets and possibly will take advantage of that (just like password). Also if you look at laravel conf files, you will notice that there are other information such as timezone, debug property, etc that are also in conf files, and you do want to version-control them. So how do you version-control such configuration files and still hide your sensitive information.
The answer is env variables. Laravel uses dotenv whose documentation can be found here. Basically these are variables that live in one file called .env in a key-value pair. E.g.
Sample contents of .env file
APP_DEBUG=false
APP_KEY=ABCDEFGH
...
Once you define your .env file as this, you can get the value using the key as such env('APP_DEBUG').
So this solves the above mentioned problem in following ways:
you keep the .env file to yourself. And you also declare another file called .env.example which is an exact replica of original file except the fact that it contains sample values, not your sensitive values. Then you pass this new example file to everyone. They will replace the sample data with their own sensitive information.
Since you are version-controlling the example file, you can version control all your conf files because they don't contain the secret. The secret is in .env files. All those conf files contain is values like these env('APP_KEY') and the actual value is replaced at run time using your .env file.
Make sure you have to set up right server credentials into .env file on your Laravel project:
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=myapp_db
DB_USERNAME=root
DB_PASSWORD=pass
Try to clean up artisan cache and restart the artisan,
php artisan config:clear
restart php artisan
when I use php artisan migrate, i get the error SQLSTATE[42000] [1049] Unknown database 'databaseName'.
But the database DOES exists! I even tried going back into terminal, logged into mysql and created the database again, and it said that database already exists!
Why is this giving me this error?
I have the same problem. When I run: php artisan migrate.
In my case I use Vagrant with scotch box.
To solve this, enter:
vagrant ssh
cd /var/www/yourproject
php artisan migrate
And all work well.
In your app/config/database.php file change the default value from databaseName to a real database name that you are trying to use in your application, something like this (for mysql driver):
'mysql' => array(
'driver' => 'mysql',
'host' => 'localhost',
'database' => 'your database name', //<-- put the database name
'username' => 'your user name',
'password' => 'your password',
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
),
One thing could be your casing. If you read the docs on case sensitivity it says:
the case sensitivity of the underlying operating system plays a part
in the case sensitivity of database and table names. This means
database and table names are not case sensitive in Windows, and case
sensitive in most varieties of Unix. One notable exception is Mac OS
X, which is Unix-based but uses a default file system type (HFS+) that
is not case sensitive.
Then go and check your application database setting found # app/config/database.php.
Something that looks like this:
'mysql' => array(
'read' => array(
'host' => '192.168.1.1',
),
'write' => array(
'host' => '196.168.1.2'
),
'driver' => 'mysql',
'database' => 'databaseName',
'username' => 'root',
'password' => '',
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
),
And double check everything.
Also try using snake_case rather than camelCase for you database name.
In my case I had MySQL installed on this port: 3308, and in Laravel env file there was 3306.