wardrobecms / core-archived

Wardrobe Core Files

Home Page:http://wardrobecms.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

How to set a different database connection for Wardrobe?

borfast opened this issue · comments

I'm trying to set up Wardrobe to use a database connection other than the one my application uses, so that I can tell Wardrobe to use a table prefix, to overcome the issues mentioned in #68.

Problem is, it seems Wardrobe's DB configuration is leaking to the rest of the application. I asked about this on laravel/framework#3712 and Taylor said I should set up a separate DB connection, so I did this in app/config/packages/wardrobe/core/database.php:

<?php

$config = Config::get('database');

$config['connections']['wardrobe'] = $config['connections']['mysql'];
$config['connections']['wardrobe']['prefix'] = 'wardrobe_';
$config['default'] = 'wardrobe';

return $config;

But it still leaks the prefix to the rest of the application. My guess is that it's because I'm changing the default key and I thought the $config array I'm creating on that file would only be used by Wardrobe but apparently it's not.

So my question is: how do I configure a database connection for Wardrobe, where I add a table prefix, but don't let it leak to the rest of the application?

The instructions in the readme file are not very clear about this:

If the default configuration is set to default it will use the host application connection. Otherwise, it will use the connection details listed in this connection array.

I'm not able to replicate having this issue.

I have tried the following few ways of going about configuring the wardrobe connection:

  • Manual Connection Description
<?php

return array(
    'default' => 'mysql',

    'connections' => array(

        'sqlite' => array(
            'driver'   => 'sqlite',
            'database' => app_path().'/database/production.sqlite',
            'prefix'   => 'wardrobe_',
        ),

        'mysql' => array(
            'driver'    => 'mysql',
            'host'      => 'localhost',
            'database'  => 'wardrobe',
            'username'  => 'root',
            'password'  => 'root',
            'charset'   => 'utf8',
            'collation' => 'utf8_unicode_ci',
            'prefix'    => 'wardrobe_',
        ),

        'pgsql' => array(
            'driver'   => 'pgsql',
            'host'     => 'localhost',
            'database' => 'database',
            'username' => 'root',
            'password' => '',
            'charset'  => 'utf8',
            'prefix'   => '',
            'schema'   => 'public',
        ),

        'sqlsrv' => array(
            'driver'   => 'sqlsrv',
            'host'     => 'localhost',
            'database' => 'database',
            'username' => 'root',
            'password' => '',
            'prefix'   => '',
        ),

    ),
);
  • Importing in the configuration from the global configuration:
<?php

$config = array(
    'default' => 'mysql',

    'connections' => array(

        'sqlite' => array(
            'driver'   => 'sqlite',
            'database' => app_path().'/database/production.sqlite',
            'prefix'   => 'wardrobe_',
        ),

        'mysql' => Config::get('database.connections.mysql'),

        'pgsql' => array(
            'driver'   => 'pgsql',
            'host'     => 'localhost',
            'database' => 'database',
            'username' => 'root',
            'password' => '',
            'charset'  => 'utf8',
            'prefix'   => '',
            'schema'   => 'public',
        ),

        'sqlsrv' => array(
            'driver'   => 'sqlsrv',
            'host'     => 'localhost',
            'database' => 'database',
            'username' => 'root',
            'password' => '',
            'prefix'   => '',
        ),

    ),
);

$config['connections']['mysql']['prefix'] = 'wardrobe_';

return $config;

Importing from the global configuration was pretty much what I did.

I should probably mention that this only happens while running tests. If I run the three migrations separately (two third-party packages, including Wardrobe, and my own application), everything works fine, both on my local env and the testing env, but when the migrations are ran in preparation for a test, things fall apart.

The following code is called in the setUp() method of my TestCase class:

Artisan::call('migrate', array('--package' => 'vendor/package'));
Artisan::call('wardrobe:migrate');
Artisan::call('migrate');

An interesting detail is that the first migration command runs normally, creating the new tables with no prefix, then the Wardrobe migration also runs normally and creates its tables with the desired prefix, but then the third migration, which should create tables with no prefix, still tries to use Wardrobe's prefix.

Here, I created a repository with a very simple application to show what happens: https://github.com/borfast/laravel_prefixes

@rtablada, any thoughts on this?

commented

I just put the configuration in app/config/packages/wardrobe/core/database.php with keys for each environment and then in a folder for each environment changed the default to use the proper one. I couldn't seem to get it to pull from app/config/database.php after upgrading Laravel from 4.0 to 4.1 and updating Wardrobe to the latest. Laravel has an over configuration problem (far too disorganized and more overrides than necessary), but in the end it worked out. I'd just redefine in app/config/packages/wardrobe/core/... and not worry about what you have elsewhere. Then you'll always know Wardrobe config is in wardrobe at least.