Laravel_5 "Database Migration"

Laravel encourages agile, iterative development, and we don't expect to get everything right the first time. Instead, we write code, test and interact with our end users, and refine our understanding.

For the job, we need a matching set of practices. We use these version control tools like Subversion, git, or mercurial to store the application's source code files, enabling us to undo errors and track changes in the development process.

However, when the application changes, there are areas where we cannot manage effectively using version control alone. In our development progress, the database architecture of the Laravel application evolves: We add a table here, rename the column, delete the index, and so on. The database changes with the application code unison.

You need a complex way to keep track of your database schema changes, usually in several ways:

• When you work within a development team, everyone needs to know about any schema changes.
• When you deploy on a production server, you need a robust way to upgrade your database schema.
• If you are working on more than one machine, you need to keep all database schemas synchronized.

Keeping database schemas synchronized with application code has historically been a cumbersome task without strict conventions and discipline for application developers to follow. The developer (or database administrator) makes the required schema changes. However, if the application code rolls back to the previous version, it is difficult to undo the database schema changes, and the database version information is inconsistent with the application code version information.

Migration is the Laravel way to help you evolve your application data architecture, and it doesn't require you to delete or rebuild the database every time you change. Not deleting and rebuilding means you don't lose data every time you change. The only change when you perform a migration is to move the database schema from one version to another, either forward or backward.

Laravel migration gives you the means to modify the database schema in an iterative way, which does not allow you to operate with SQL, but rather allows you to use PHP code. The Laravel schema generator allows us to quickly create database tables and insert columns or indexes. It uses clean and expressive syntax to manipulate the database. You might think that laravel migration is the version control of a database.

By defining a higher-level interface to create and maintain a database schema, you can define it in a database-independent way. Create a table by using PHP, define columns and indexes, write the schema once and apply it to any supported database backend. The additional benefit is that Laravel tracks which migrations have been applied and which ones still need to be applied.

Basic knowledge of migration

A laravel migration is simply a PHP source file in your application's app/database/migrations directory. Each file contains a set of changes to the underlying database. Changes to the database are in PHP code rather than database-specific SQL. Your PHP migration code is eventually converted to the DDL that matches your current database, which makes switching the database platform very easy. Since the migration code is kept in its own directory, it is important to include it in version control just like any other project code. Laravel migration is run using the Artisan tool with the command line display.

Migrating File Naming conventions

In older versions of Laravel, migrated files have simpler names, such as 001_create_employees_table.php. Laravel 3 (Laravel 4.1 and the same) brings a new naming convention where the first part of the name is changed from a sequence number to a longer time, like 2014_03_11_032903_create_employees_table.php. The name of the file is in the form of yyyy_mm_dd_hhmmss_some_meaningful_name.php, which means that a UTC timestamp is identified followed by a migration name.

The new wider name helps to avoid name collisions, and if you are a developer working in a team, you can check your migration.

Additionally, Laravel migrates the timestamp of the files so that they can be executed sequentially. Timestamp numbers are key to migration because they define the order in which the migration is applied in the standalone migration version number.

Like SQL scripts, migrations start at the top, which is more needed for these files to be executed. Sequential execution removes the possibility of attempting to insert a column when the table does not exist.

Although you can create migration files manually, it is much easier (and less error prone) to generate migration scripts using the Artisan tool. You can edit these files as needed later.

Run migration forward and backward

Use the artisan tool to migrate to a database. Laravel provides a set of artisan tasks that can be attributed to running a specific set of migrations.

[ note] You can run the artisan list Same View artisan supported task lists, most data migration-related tasks are prefixed with migrate: .

There are only a few common tasks you need to know:

• Migrate:install
  The first time you use a migration-related artisan task might be migrate:install. Internally, Laravel uses special tables to keep track of which migrations have been run. To create this table, you only need to use the Artisan command-line tool:
  $php Artisan Migrate:install
• Migrate
  You will run the migrate task frequently to update your database to support the most recent tables and columns that you add to the application. In its most basic form, it only runs the up () method for all migrations that have not been run. If there is no such migration, it exits. It will run these migrations based on the date of the migration.
• Migrate:rollback
  Errors are occasionally made when writing migrations. If you've already run the migration, then you can't just edit the migration and run the migration again: Laravel assumes it's already running the migration, then when you run artisan migrate again, you won't do anything. You must use artisan migrate:rollback to roll back the migration, then edit the migration, and then run artisan migrate to run the correct version.

In general, editing an existing migration is not a good idea: you and your colleagues will need extra work, and this is a headache-if the existing version of the migration is already running on the production machine. Instead, you need to write a new migration to perform the required changes.

[Note]artisan Migrate:rollback deletes the last migration app.] Laravel go back to the entire migration "operation". Therefore, if the last migration command ran 15 migrations, the 15 migrations will be rolled back. Note that when you delete a column or table, data is lost.

• Migrate:reset
  Rollback of all migrations (all tables and data will be deleted)
• Migrate:refresh
  The Artisan migrate:refresh task deletes the database, re-creates it, and loads the current schema. This is a quick and easy way to run a reset and then rerun all migrations.
• Migrate:make
  The Artisan migrate:make command tells Laravel to generate a migrated file skeleton (which is actually a PHP file) that is stored in the App/database/migrations folder. You can then edit this file to enrich your table/index definition. Then, when the artisan migrate command runs, artisan queries the file to generate the actual code for the SQL DDL.

Laravel_5 "Database Migration"