[Proposal] Namespacing database tables
seblavoie opened this issue · comments
Correct me if I'm wrong, but I think it would make sense to namespace the table names as Wordpress does (eg. wp_users). Since wardrobe seems to aim at being included as part of bigger apps, I think it would be good to avoid using the users table for an app that already has users but still want a blog section?
I haven't tried this but it should be possible. After running composer create-project wardrobe/wardrobe then open the wardrobe config/database and a prefix before doing the install.
Yeah. You have a completely separate database connection. My advice is don't use the same Database at all for your blog vs your app. You can use any connection config that you would like to prefix, use a different database, or even a whole different server/driver combo!
Okay thanks for the tips. Although for the sake of people wanting to keep it simple (one database only) the mysql prefix does not seem to be taken in account in the models $table variables. Would there be a way to simply append DB::getTablePrefix() to the $table variables? I don't know much about mysql stuff, so I might just be missing something.
Pretty sure that the prefix in the config options take this into account. Haven't tested prefixing but if the config is set, it should work for building migrations and actually eloquent calls.
Yes, the eloquent call will be affected by the prefix from the main database.php prefix but not from the prefix in config/packages/wardrobe/core/database.php, that's where I thought there could be some specific prefix. Maybe it's just the wrong way to do it, but I just thought it would be nice to have a way to prefix tables easily.
What driver do you set in the wardrobe database config file?
MySQL
I'll chime in to add another vote for prefixing the tables by default (I think that should be required and even done automatically for Laravel packages, but that's another story), especially if you're creating a "users" table.
In my case, I have an existing application to which I need to add Wardrobe but I need to keep my authentication mechanism and use it for Wardrobe, so getting rid of my users table is a no-go.
Duplicating the database configuration is also a no-go for me (and should be for anyone, unless there's a strong reason to do it), so what I did so far was convince Wardrobe to use a prefix but maintain the rest of the DB configuration. I changed app/config/packages/wardrobe/core/database.php to this:
<?php
$config = array(
'default' => 'mysql',
'connections' => Config::get('database.connections')
);
$config['connections']['mysql']['prefix'] = 'wardrobe_';
return $config;
@borfast I can understand the thought of not using the default connection and automatically prefixing the tables, however the primary function of Core is to support the the Wardobe functionality as a stand alone app. For this, it makes sense to not require a user to know about multiple database connections and such.
For the application developer who wants to add Wardobe's functionality to their existing project we do suggest using a separate connect. IMO prefixing is nice, but doesn't save you from a situation where you may want to reset your application's database but not your blog or vice versa. Ideally, I suggest using a different database so that if you do DROP DATABASE blog you won't loose your application data.
@seblavoie sorry to get back to you so late on this, can you paste your app/config/database.php (please don't include your passwords) and your app/config/packages/wardrobe/core/database.php (once again delete any passwords to empty strings).
@rtablada, I completely understand what you say about the role of Core, but I still think it would make sense to allow for the simple use case that you already have, and allow for a more complex setup. Everyone would be happy.
In my case, I need the blog users to be the same as the rest of the application, so I cannot have a separate users table just for Wardrobe, much less a completely separate database. Others seem to have the same issue: http://wardrobecms.com/forum/6-changing-the-auth-provider and #57