How do you create and run migrations in Laravel?

In Laravel, migrations are a type of version control for database, allowing easily modify and share the application's database schema. Migrations are typically paired with Laravel's schema builder to easily manage application's database schema.

???????????????? ?? ??????????????????: Use Laravel’s Artisan command-line tool to create a new migration file: ?????? ?????????????? ????????:?????????????????? ????????????_??????????_?????????? ???????????? ?????? ????????????: Edit the generated migration file in database/migrations. Use the up method to define the table schema and the down method to reverse the changes. ?????? ?????? ??????????????????: Apply the migration to the database by running: ?????? ?????????????? ?????????????? ???????????????? ?? ??????????????????: Undo the last batch of migrations: ?????? ?????????????? ??????????????:???????????????? ?????????????? ????????????????????: Rolling back all migrations ?????? ?????????????? ??????????????:??????????????

Laravel migrations are instrumental in maintaining a structured and version-controlled database schema. They provide a straightforward way to create and modify database tables using PHP code. Here is example: use Illuminate\Database\Migrations\Migration; use Illuminate\Database\Schema\Blueprint; use Illuminate\Support\Facades\Schema; class CreatePostsTable extends Migration { public function up() { Schema::create('posts', function (Blueprint $table) { $table->id(); $table->string('title'); $table->text('content'); $table->timestamps(); }); } public function down() { Schema::dropIfExists('posts'); } }

In Laravel, create and run migrations using the Artisan command-line tool. Use php artisan make:migration to generate a new migration file. Define the table structure in the created file, then execute php artisan migrate to apply changes to the database. For rollback, use php artisan migrate:rollback. Migrations simplify database schema management and version control, enabling seamless updates and reversions in Laravel applications.

To create a migration, we use Artisan command-line tool. Example: 'php artisan make:migration create_users_table'. This command will create a new migration file in the database/migrations directory. The migration file will contain two methods: up and down. It is also important to know that when creating columns it is essential to use the correct data type. Laravel supports various data types such as string, integer, boolean, date, timestamp, etc. We can create indexes and define unique columns to improve performance and ensure data integrity. Example: $table->unique('email'); $table->index('state');

php artisan make:migration create_users_table This command will create a file with date in /database/migrations/create_users_table-XXX.php

You should name your migration files descriptively so that it’s easy to understand their changes to the schema. For example, instead of `create_table`, use `create_users_table` or `add_email_column_to_users_table`. Also, when typing `make:migration` command, you don’t necessarily have to use the underscore(_) symbol between parts, like `create_transactions_table`. You can wrap your new migration name in quotes to avoid typing those underscores/dashes, And it still auto-fills the table name and correct statement type. For example, php artisan make:migration "create posts table"

The `path` option can be mentioned with the make migration command as below if you need the migration file to be created/placed in a different directory or in a subdirectory. `php artisan make:migration add_status_to_users_table --path=database/migrations/subdirectory `

If you set APP_ENV=production you need to add --force to run the artisan command. - Run all migration: php artisan migrate --force - Run only one migration: php artisan migrate --path=database/migrations/2021_08_25_123456_add_status_to_users_table.php --force

In my experience, I used to utilize the command "php artisan migrate:fresh" to run migrations. This command is dangerous because it drops all existing tables and recreates them, resulting in the loss of all my data. It was a significant lesson for me to differentiate between "php artisan migrate" and "php artisan migrate:fresh". Please be cautious when using "php artisan migrate:fresh" to avoid losing any existing data.

??Brief description: - When setup new DB, you can run all migrate php artisan migrate - Run one migrate: php artisan migrate --path=database/migrations/2024_09_25_203481_create_users_table.php

In order to run migrations inside your Laravel project, you will run the command (php artisan migrate). This command effectively runs all the pending migrations that haven't been running already. When you run this command, Laravel will run the migrations in the order specified using the timestamp in the name of the migration file. By default, if your APP_ENV variable is set to production, then Laravel will prevent you from running migrations. To overcome this restriction you can pass the (--force) flag to the command. Also by default, Laravel will run the set of all existent pending migrations as a single batch and assign them a number. To change this behavior, use the (--step) flag which will give each migration a different batch number.

In addition to running the pending migrations using `php artisan migrate`, you can run `php artisan migrate:fresh` to drop the existing tables and run all the migrations from the beginning. But you shouldn't run this command in production, because it'll drop the existing tables first. So, you'll lose all the data. This is only useful in development environment. You can also pass `--seed` flag to migration commands to run the Database seeders after the migration is done. If you want to see which migrations have run thus far, you may use the `migrate:status` command. If you would like to see the SQL statements that will be executed by the migrations without actually running them, you may provide the `--pretend` flag to the migrate command.

If you need Rollback one specific migration, use : php artisan migrate:rollback --path=YourMigrationFileNamewithPath These command useful for me when you don't want to rollback the last batch migration. Also if you need to rollback one migration only in a batch

You can undo migrations with `php artisan migrate:rollback`, which reverts the last batch. A batch refers to a group of migrations run together. The `--step` option allows you to rollback a specific number of batches, giving you granular control over how many changes are reversed.

How to Rollback Migrations To rollback the last batch of migrations, use php artisan migrate:rollback. This runs the down methods of the last batch in reverse order. To rollback specific batches, use --step, e.g., php artisan migrate:rollback --step=2. Precautions Before Rolling Back - Backup Your Database: Prevent data loss with a backup. - Check for Destructive Changes: Avoid dropping critical tables or columns. - Maintain Integrity: Ensure foreign key constraints remain intact. - Test First: Run the rollback in a dev or staging environment. - Communicate: Inform your team to minimize disruptions. - Review Dependencies: Ensure rollback compatibility with your code. By following these steps, you can safely rollback migrations.

If you ever need to rollback the last batch of migrations, you can use: php artisan migrate:rollback And to rollback all migrations, you can use: php artisan migrate:reset These commands are useful for reverting changes made by the migrations. Remember to always make a backup of your database before running migrations, especially in a production environment, to avoid data loss.

Because rollbacks usually drop columns or tables it is not usually recommended to run them in production as you risk losing data - especially if you never tested the rollback! Taylor Otwell (creator of Laravel) says he never uses them 'moving forward only'. They can however be handy during development where without a rollback you have to manually undo the migration before it will run again. If you do add a down method, make sure you test that it only ever undoes what the migration itself did!

We must be careful when using Migrate: Reset or Migrate: Refresh as both commands will delete all data from the tables. I recommend backing up data before running these commands, especially in production environments.

Ein alternativer Ansatz ist `php artisan migrate:refresh`, um alle Migrationen zurück zu rollen und erneut auszuführen. Hiermit werden ebenfalls alle Tabellen und Inhalte gel?scht, allerdings im Nachgang direkt wieder angelegt.

The `php artisan migrate:reset` command rolls back all migrations, essentially returning the database to its original state. This is ideal for starting fresh, but it also wipes out all data, so caution is necessary. While resetting migrations is useful for developers working on a local environment where data isn’t critical, using it in production could lead to catastrophic data loss. Always ensure you have backups or are using the command in non-critical environments.

To reset all migrations in Laravel, you can use the `php artisan migrate:reset` command. This command will rollback all the migrations that have been run, in reverse order. It is important to note that this command will also delete all the data in your tables, so be cautious when using it. Resetting migrations is useful when you want to start fresh and rebuild your database schema from scratch.

You can run the `php artisan migrate:refresh` command if you want to rollback all the migrations and run them again. Unlike `migrate:fresh` command, which drops all the tables first, this command will run all the `down` methods from the migrations to rollback. In the development environment, this helps to check that the rollback logic are written properly.

The migrate:refresh command will rollback all migrations, and then re-run them. It's useful when you need to refresh the entire database: php artisan migrate:refresh

There are a few things we should keep in mind: - If you need to change the schema for an existing table that is already in production, don't update in it's existing migration file. Write a new migration file to do the change and run the migration in production. - Make sure to run the migration in development and staging environment first before running it in production. This minimizes the risk of data corruption and silly mistakes. - Do not leave the `down` method in migrations empty. Rather write proper rollback logic there. You don't know when you'll need to rollback. - Be careful about destructive schema changes like dropping columns or tables, renaming columns etc. Because it can lead to data loss.

Benefits of migrations Database version control: facilitates the management of database changes over time. Automation: allows database changes to be automatically applied across different environments (development, testing, production). Collaboration: enhances collaboration among developers, as migrations are versioned and can be shared via version control (like Git). Simple rollback: enables easy rollback of changes, aiding in quick problem resolution.

Ich bevorzuge "forward migration only"-Strategie. Sprich: die down()-Methode ist mit entsprechendem Kommentare gefüllt oder komplett nicht existent. Au?er bei der Create-Table-Migration, damit Testing einfacher m?glich ist. Warum forward only? Es soll explizit klar sein, welchen Status die Applikation gerade hat, nachvollziehbar über die ausgeführte Migration. Insbesondere wenn mehrere Environments im Einsatz sind m?chte man. Bei einer reverse (down)-Migration werden in fast allen F?llen Daten gel?scht. Das ist jedoch klarer und nachvollziehbarer, wenn ich das explizit über eine neue Migration mache.

Make sure you test you migration against all DB backends you use. You might run and develop with MYSQL but use SQLite for automated testing, and SQLite sometimes requires two migration methods to work. It is also worth checking complex manipulation migrations against a database of similar size. Your migration might run fast locally on two test rows, but if production has a million rows will it take a million times longer? Production should not be where you learn the answer that question!