I was using the Entrust roles and permission library for Laravel and Lumen. Although I had a reason to use it differently from the way it was supposed to be used because of my unique case. I needed to have multiple instances of of a user with the same role differentiated by a certain foreign key.
Lets assume I wanted a user to have same role for different jobs or different roles for different jobs so I added a job_id to the role_users table to help me filter the roles a user has for for a particular job..
This just means a user can be an admin for job1 and an admin for job2.. This posed a problem because Entrust some how made primary keys of both role_id and user_id on the role_users table..
First I didn't think that was possible, plus I don't understand why.. This also means that I couldn't have multiple instances of the same role_id and user_id which i wanted. I did a little research and found out I could drop a primary key using $table->dropPrimary() method.
I did this in my up() method, although the action needs to be replicated in my down method. I couldnt' create a primary key there because if multiple instances already exist it would thrown a fatal exception.
Basically I need a way to drop the primary key on condition that it exists so I don't have to recreate it in the down method.
You don't need to put anything in down() in this case.
My usual rule for putting something in down() is when the up() contains something that will prevent my migration to rollback successfully.
In your case dropping a primary key won't affect the rollback in any way.
If you really need to have this rollback. You could add some script that handles duplicates in your table and apply the primary key again
Related
While designing the database for a laravel software using MYSQL, is assigning foreign keys relevant or does Laravel take care of that "Software side".
In the migration we have something like
Table Example:
$table->unsignedBigInteger('user_id');
should i modify the example table in phpmyadmin and make user_id a foreign key? is there a better way or is this not relevant or necessary?
You should define foreign key constraints in your migration. When using code base you should make all the changes using migrations.
Additionally by defining foreign key you actually build a relation between 2 tables otherwise this relation will be at code level. When relation is built database will restrict to have only values which actually exists in main table. Using foreign key you can also do cascading (on update and delete) at db level.
Reference what are the advantages of defining a foreign key
Why should I use foreign keys in database?
if use Laravel 7 ,you can use this short that is a column name user_id foreign to ID user in the table users :
$table->foreignId('user_id')->nullable()->constrained()->onDelete('cascade');
I'm trying to create a login/register system for a project using laravel, and since it's my first time, I've been running into a lot of troubles, so I'd ask to please forgive me for any extremely dumb mistakes I've made.
I've already succesfully added a new custom field to the default registration screen, but in my modified users table, I also have two foreign keys referencing other tables ('gameInfo_id' refers to the 'gameInfo' table, and 'role_id' refers to the 'roles' table)
This is the error I'm getting:
Does this mean I have to find a way for the foreign key to be filled in automatically? If so, how would I go about doing this?
I've done some googling and found that this usually seems to be issue, but I've never found a clear solution.
Thank you!
Here's my migrations in the users table:
Schema::create('users', function (Blueprint $table) {
$table->increments('id');
$table->string('firstName');
$table->string('lastName');
$table->string('email')->unique;
$table->string('password');
$table->integer('gameInfo_id')->unsigned();
$table->integer('role_id')->unsigned();
$table->timestamps();
});
Schema::table('users', function($table) {
$table->foreign('gameInfo_id')->references('id')->on('gameInfo');
$table->foreign('role_id')->references('id')->on('roles');
});
gameInfo is a table of scores that the user would achieve in a game we're also making. What I'm trying to make happen is, when a new user registers an account, it creates a new row in gameInfo, to which the gameInfo_id foreign key would refer. The columns of this newly created row could be set to 0 by default if it helps
I would do it the other way around.
I would reference the user on the gameInfo table with a user_id column.
that way, the user hasMany gameInfo, and a gameInfo belongs to a user. Since the Game info isn't created before the user is created, and has played a game.
Does that make sense?
If the users table already contains datasets, where some of them don't have existing gameInfo_id or role_id, you can't add an foreign key constraint to the table.
The table must be in an valid state, before you add an foreign key constraint.
That means: Adding an new foreign key constraint to an existing field is not the best idea. Doing it anyway, you have to fix the integrity before.
If your still on an development environment, the best way to fix this would be to start all over again with migrate:refresh.
If the system runs in production with users, you have to fix all users with invalid or unset gameInfo_id and role_id. If you have just a few users, you could do this by hand. If you have many users, you could do some magic inside the migration script (iterate over all users and add missing references, before you add fk constraints).
Since the ->nullable() didn't seem te be recognized by laravel, I instead decided to give each column in gameInfo a default value of 0, which works just fine for me as well.
On the other hand, reversing the FK relationship between users and gameInfo also worked, so my problem's been resolved!
Thank you all very much for your answers, every contribution is appreciated greatly!
I am new to Laravel, so a bit new to this framework's best practices. I am trying to understand the best way to approach creating a database using migrations.
The few examples I found on the web, including the Laravel documentation here and here, seem to refer to migration scripts that handle only one table. I am creating an application with around 10 tables, all interrelated with foreign keys between them, some with many-to-many relationships.
Is the recommended approach to have one migration file per table? If so why? (What are the disadvantages of putting all table creation scripts in one file, if any?)
What about foreign keys and relationships? How does one enforce these relationships, and the order in which migrations are executed such that if table1 references a column in table2, table2 is created before table1?
What about many-to-many relationships? Does the relationship (pivot) table need to be created manually too through a separate migration script? If yes what ensures that it is created after the 2 related tables?
During development of your application I don't think you should care too much having only one table per migration, sometimes it's just easier to have some tables togheter in a single migration, but as soon as your system go to production, you will not be able to keep working like that, because you will only migrate in production and probably never rollback, so your migrations will be really small, sometimes you'll have a migration for a single column creation.
The advantages of putting tables in different migrations is the same of having a thin class, the less information you have in one file, the easier is to manage and make changes on it. So if you put all tables in a single migration, it gets harder to maintain, but that's really up to you.
Foreign keys are a good example of why you should create one migration per table and even per foreign key: every time you rollback a table related to foreign keys, you must first delete all foreign dependencies, that's why Laravel creates a migrates them all in the same order, it helps you never screw a table drop. So, create your tables migrations first, then you create your foreign keys migrations, so when you rollback it will first rollback the constraints and then the tables.
I create foreign keys for a table in the same migration of that table, unless I have too much cross foreign keys. But I always create a foreign key in a separate Schema::table() command, because some databases need you to have the column before attaching the constraint to it:
public function up()
{
Schema::create('statuses', function(Blueprint $table)
{
$table->string('id', 64)->primary();
$table->string('user_id', 64)->index();
$table->text('body');
$table->timestamps();
});
Schema::table('statuses', function(Blueprint $table)
{
$table->foreign('user_id')
->references('id')
->on('users')
->onUpdate('cascade')
->onDelete('cascade');
});
}
About many to many, if you create the table and foreign keys togheter, you should first create the master and then the pivot tables, but if you are creating your foreign keys in separate migrations, first create the tables (order will not matter much, but it's also better to be organized in those cases) and then the migrations for the foreign keys.
During development I do a lot of changes in my tables, so I'm always coming back to them, so this is what I use to do, when I'm altering a migration:
1) php artisan migrate:reset many times
2) Alter migration
3) php artisan migrate
If I'm just creating a new one, usually I won't have any problems, because migrations are usually idepotent.
Your last question was already answered, but I'll say it again: Laravel name the migrations files using timestamps, the way you will never have a migration being ran before another one created before it:
2014_07_16_190821_create_statuses_table
And the name of the migration matter, because this one above will create this class:
CreateStatusesTable
So one thing you must do is to create every migration with a different name, otherwise you will end up with two classes with the same name and, not Laravel, but PHP will complaint about it.
This is for a sort of proof of concept draft to get things working, but don't want to have completely crap code. For my database, I tried to get true foreign key relations going using innoDB, but couldn't get it.
Instead of using foreign keys, I decided to just pull mysql_insert_id() after inserts, saving it as a variable, then putting that variable into the related table.
Is this horrible? Everything seems to work well, and I'm able to connect and relate ID's as needed. What benefits would using foreign keys give me over my method (besides updates/deletes cascading)?
To create a relation (master->detail), you have to always supply the keys by yourself, either using mysql_insert_id, natural keys or key generated by your applications. The FOREIGN KEY is not going to make that work for you.
What FOREIGN KEY does is
Helping you enforce the relationship/the integrity of your data (so the "detail" record does not point to an invalid parent)
Handles deletion or key alterations of master records (ON DELETE ..., ON UPDATE ...).
It's also creating an index in your "detail"-table for the "master_id"-row if it doesn't exist yet (okay, you could also do that without FOREIGN KEY)
Has also some kind of documenting purpose for example an ERM-tool could reengineer the relationship model from your schema (okay, this point is a slight long shot)
The cost of adding the FOREIGN KEY constraint statement is small compared to its benefits.
As I read J.Gilmore Zend Book (Models section):
class Game extends Zend_Db_Table_Abstract
{
protected $_primary='id'; //line 4
}
[..]Line 4 identifies the table's primary key.By default the framework will
presume the primary key is an automatically incrementing integer named id,so
this line is not necessary [..]
I have a question:
Do I need to manually set primary and foreign key while building a table
(Ex. in phpmyadmin with something like "PRIMARY KEY (id),FOREIGN KEY (post) REFERENCES users (id)
ON DELETE CASCADE")?
Or I can handle tables relationships and fields nature just by referring to Zend code using $_primary,$_dependentTable,$_referenceMap and so on?
thanks
Luca
Both. Although you can get away with an ORM dealing with relations, the database ensures at low-level those relations are respected. Always let the database do its job as much as possible, it is built for handling relations and preventing data corruption. What if your ORM has a bug?
As a somewhat related example, say you have a field declared as int in database, you are responsible as a developper for making sure you use int's in your queries, but the database enforces that rule at a lower level, protecting your data in case you don`t.
You should define the primary/unique keys and any other indexes properly when you create the table.
After you've done this in 99% of cases Zend_Db will understand what's going on as it's able to read the table metadata and derive the primary key from that.