Also If someone doesn't want to follow the default name pattern in a foreign key migration,we can always pass the table name in the constrained method. $table->foreignId('sender_id')->nullable()->constrained('users'); $table->foreignId('recipient_id')->nullable()->constrained('users');
Had this issue yesterday, i created seperate migration files for adding foreign keys. This migrations run after tables are created.
Před 3 lety+1
I'm a huge fan of this solution. I always create separate migrations to work with FK. And also make sure of down methods are correct by running php artisan migrate:rollback before commit and push the code.
Ah, yes, timestamp manipulation - that has saved my ass countless times when I mess up migrations. In the worst case scenario - there's option to create a command that would list all the migration file names in the order you need them to be run, implement File:exists(.. check on those files, wrap it all up in transactions, loop through each migration file and run it and there you go... but then you pretty much lose all the migrator features. Works well as a temp solution just to get things working but has to be refactored by timestamp manipulation so that it migrates automatically in the order needed.
So is this a bug in Laravel? Or is it expected behavior? I feel like Laravel should be wrapping everything in the up (or down) function into a single db transaction such that should any part fail, everything should roll back. The fact that migrations could fail but still succeed partially seems unintuitive.
Povilas, hi! The way you showed at 3:00 seems as dirty way for using this migration later for other developers, isn't it? What do you think about it? In my experience I saw this workaround sometimes, but isn't it better to make your migration clear via some tricks on local machine and then push clear migrations without any if statements to the project repository?
It actually depends on the state your code is in, whether you pushed it to the repository or not yet. If it's pushed already, then you need to fix it, one way is like I showed (but not the only way). If you haven't pushed yet, then perhaps the best way is to delete the table manually locally.
There's "migrate:rollback" for a specific migration if you have down() method provided, but that's only a partial solution. And no, there's no command to create migrations from DB, there are only some packages for that and they would still not create EXACTLY the same migrations as they were.
Pls don't stop these tutorial series, we need your lessons 🙌🏻👍🏻
Thanks man. You just ended my six hour of debugging. Love from Ethiopia
Also If someone doesn't want to follow the default name pattern in a foreign key migration,we can always pass the table name in the constrained method.
$table->foreignId('sender_id')->nullable()->constrained('users');
$table->foreignId('recipient_id')->nullable()->constrained('users');
migrate:rollback also works to fix mistakes.
The problem becomes when you have an automatef deployment, you must be very sure that your migrations will not fail on production
Had this issue yesterday,
i created seperate migration files for adding foreign keys.
This migrations run after tables are created.
I'm a huge fan of this solution. I always create separate migrations to work with FK. And also make sure of down methods are correct by running php artisan migrate:rollback before commit and push the code.
Good idea
Ah, yes, timestamp manipulation - that has saved my ass countless times when I mess up migrations.
In the worst case scenario - there's option to create a command that would list all the migration file names in the order you need them to be run, implement File:exists(.. check on those files, wrap it all up in transactions, loop through each migration file and run it and there you go... but then you pretty much lose all the migrator features. Works well as a temp solution just to get things working but has to be refactored by timestamp manipulation so that it migrates automatically in the order needed.
you are awesome, your lesson make laravel easy and easy
Excellent SIR.
I was looking for the same problem
thanks brow, ordered the migrations resolved my problem thansk
Do have example migration old PHP project without migration table to Laravel project.. please 🙏
No I haven't done anything like this myself
@@LaravelDaily thanks sir
You have your fans now. Keep it up.
So is this a bug in Laravel? Or is it expected behavior? I feel like Laravel should be wrapping everything in the up (or down) function into a single db transaction such that should any part fail, everything should roll back. The fact that migrations could fail but still succeed partially seems unintuitive.
Povilas, hi! The way you showed at 3:00 seems as dirty way for using this migration later for other developers, isn't it? What do you think about it? In my experience I saw this workaround sometimes, but isn't it better to make your migration clear via some tricks on local machine and then push clear migrations without any if statements to the project repository?
It actually depends on the state your code is in, whether you pushed it to the repository or not yet. If it's pushed already, then you need to fix it, one way is like I showed (but not the only way). If you haven't pushed yet, then perhaps the best way is to delete the table manually locally.
thank you
Which editor is this? PHPStorm?
Yes, with Material Darker theme.
Amazing! Thank you
That was so usefull.
Thanks very much
thank you very much you are the best
thanks sir.
which one do you prefer for api authentication (JWT, Sanctum, or Passport)?
Sanctum.
It is possible to reverse migrations? Use an existing dB with data and create migrations files with present data ? Another top video, thanks.
There's "migrate:rollback" for a specific migration if you have down() method provided, but that's only a partial solution. And no, there's no command to create migrations from DB, there are only some packages for that and they would still not create EXACTLY the same migrations as they were.
thanks:)
Need help please
U D Best
create in the past" ...))
thx a lot sir, i was confusing looking into my code.. but the problem is the *timestamp* while creating migration 🥲🥲