We found 23 results for "migrations".
When analyzing Laravel project performance, I often see that the underlying problem reasons are poor...
In Laravel, if we want to have a DB value calculated on the fly, we often use Mutators. But we can also perform calculations on the database level with generated virtual/stored columns.
Recently I've found a few interesting tools that help generate Laravel migrations automatically from your already existing database schema. In theory it looks very cool, but we decided to test them - I asked a colleague to actually try them all out with real demo-projects. How do they generate filenames and field types? Additional rules? Foreign keys? Do they actually work? Let's take a look.
On the last episode of Laravel Podcast, Taylor Otwell said something controversial but I had a gut feeling about it for a long time. So, do you actually use down() method in migrations, and rollback them?
Our team is here to help. Ask us anything about Laravel development and we'll get back to you with personalized guidance.
In this video, I decided to share less-known things I've learned about Laravel migrations while working with Laravel over the years.
If you have a set of options, better define them in PHP Enum than DB Enum. Let me explain.
There are a lot of sub-topics in this video. Why do you need foreign keys? What happens if you don't create them? How to override default errors? Check for child records on the front-end and the back-end? Use if-else or try-catch? Let's dive in.
If you want to check what migrations are executed or not yet, no need to look at the database "migrations" table, you can launch `php artisan migrate:status` command.
Laravel Migrations Generator: Automatically generate your migrations from an existing database schema
There are quite a lot of commands for the migrations that look similar on the surface. Let me show you how they work, in practice.
I see various bugs and problems people face with foreign key migrations, so I decided to talk about different syntax options and things to know.
If you have a lot of files in the database/migrations folder, is it a big deal, or you can ignore it as not a problem? Let's discuss this.
If you want to add a few new columns and specify their order, you can do it with after() in MySQL, also grouping a few columns together.
In addition to the default "make:migration create_xxxxx_table" syntax, there are other ways to generate the same class, but in a shorter way.
There is one typical mistake that you may make and not even notice the bug it causes.
A quick trick I remembered while working with a new upcoming demo project.
Migrations are a really useful tool to keep the database structure in sync with all environments and for all team members. And whenever we generate a new migration - its filename has a pattern of date_time_name.php. But what if you need to add a table which was in the database long time ago and created manually? How to add it into migrations folder and specify its time in the past?
If you want to add an index to the column in Laravel migrations and you're not sure if that index already exists, how to make sure that no error happens when running migrations?
When creating the foreign key migrations in Laravel, a short syntax is constrained(). With that, it's easy to make one mistake related to Column modifiers.
Laravel has a great database migration mechanism, but there are some things missing there. For example, what if you want your IDs start with some number, like 140001, 140002 etc?
While working on migration files in Laravel, it's relatively easy to forget one small detail which will restrict you from creating foreign keys. Let me tell you more.
Sometimes, especially in bigger projects, we run into issue of writing a create migration for the same table, or even column that already exist. Luckily, Laravel has a quick way of checking it.
By default, Laravel migration mechanism stores all the operations in database table migrations. Did you know that you can change it? I will show you how and why would you need it.
