Database migration can be understood as version management of the database structure, which can effectively solve the management of the database structure across members of the team.
The generated migration files are located in the `migrations` folder in the root directory, and each migration file includes a timestamp so that the migration program can determine the order of migrations.
The `--table` option can be used to specify the name of the data table. The specified table name will be generated in the migration file by default.
The `--create` option is also used to specify the name of the data table, but the difference from `--table` is that this option generates a migration file for creating a table, while `--table` is a migration file for modifying the table.
The migration class will contain `2` methods by default: `up` and `down`.
The `up` method is used to add a new data table, field or index to the database, and the `down` method is the inverse of the `up` method, which is the opposite of the operation in `up`, so that it is executed during rollback.
Some migration operations are destructive, which means that data loss may result. To prevent someone from running these commands in a production environment, the system will confirm with you before these commands are run, but if you wish to ignore these confirmations, force To run a command, you can use the `--force` flag:
If you want to roll back the last migration, you can use the `migrate:rollback` command to roll back the last migration. Note that a migration may contain multiple migration files:
You can also set the number of rollback migrations by appending the `step` parameter to the `migrate:rollback` command. For example, the following command will roll back the last 5 migrations:
Specify the number of rollbacks and rebuilds with the `--step` parameter. For example, the following command will rollback and re-execute the last 5 migrations:
Create a new database table with the `create` method. The `create` method accepts two parameters: the first parameter is the name of the data table, and the second parameter is a `Closure`, which will receive a `Hyperf\Database' to define the new data table \Schema\Blueprint` object:
Before renaming a table, you should verify that all foreign key constraints on the table have an explicit name in the migration file, rather than letting the migration program set a name by convention, otherwise, the foreign key's constraint name will refer to the old table name .
If multiple databases are managed at the same time, different migrations will correspond to different database connections, then we can define different database connections in the migration file by overriding the `$connection` class attribute of the parent class:
Define the definition or change to be performed by the migration file within the `Closure` of the second parameter of the `table` or `create` method. For example, the following code defines a string field of `name`:
| $table->bigIncrements('id'); | Increment ID (primary key), equivalent to "UNSIGNED BIG INTEGER" |
| $table->bigInteger('votes'); | equivalent to BIGINT |
| $table->binary('data'); | equivalent to BLOB |
| $table->boolean('confirmed'); | equivalent to BOOLEAN |
| $table->char('name', 100); | equivalent to with length CHAR |
| $table->date('created_at'); | equivalent to DATE |
| $table->dateTime('created_at'); | equivalent to DATETIME |
| $table->dateTimeTz('created_at'); | equivalent to with time zone DATETIME |
| $table->decimal('amount', 8, 2); | equivalent to with precision and base DECIMAL |
| $table->double('amount', 8, 2); | equivalent to with precision and base DOUBLE |
| $table->enum('level', ['easy', 'hard']); | equivalent to ENUM |
| $table->float('amount', 8, 2); | equivalent to with precision and base FLOAT |
| $table->geometry('positions'); | equivalent to GEOMETRY |
| $table->geometryCollection('positions'); | equivalent to GEOMETRYCOLLECTION |
| $table->increments('id'); | Incrementing ID (primary key), equivalent to "UNSIGNED INTEGER" |
| $table->integer('votes'); | equivalent to INTEGER |
| $table->ipAddress('visitor'); | equivalent to IP address |
| $table->json('options'); | equivalent to JSON |
| $table->jsonb('options'); | equivalent to JSONB |
| $table->lineString('positions'); | equivalent to LINESTRING |
| $table->longText('description'); | equivalent to LONGTEXT |
| $table->macAddress('device'); | equivalent to MAC address |
| $table->mediumIncrements('id'); | Increment ID (primary key), equivalent to "UNSIGNED MEDIUM INTEGER" |
| $table->mediumInteger('votes'); | equivalent to MEDIUMINT |
| $table->mediumText('description'); | equivalent to MEDIUMTEXT |
| $table->morphs('taggable'); | equivalent to adding incremental taggable_id and string taggable_type |
| $table->multiLineString('positions'); | equivalent to MULTILINESTRING |
| $table->multiPoint('positions'); | equivalent to MULTIPOINT |
| $table->multiPolygon('positions'); | equivalent to MULTIPOLYGON |
| $table->nullableMorphs('taggable'); | equivalent to nullable version morphs() field |
| $table->nullableTimestamps(); | equivalent to nullable version timestamps() field |
| $table->point('position'); | equivalent to POINT |
| $table->polygon('positions'); | equivalent to POLYGON |
| $table->rememberToken(); | equivalent to nullable version VARCHAR (100) of remember_token field |
| $table->smallIncrements('id'); | Increment ID (primary key), equivalent to "UNSIGNED SMALL INTEGER" |
| $table->smallInteger('votes'); | equivalent to SMALLINT |
| $table->softDeletes(); | equivalent to add a nullable for soft delete deleted_at field |
| $table->softDeletesTz(); | equivalent to add a nullable for soft delete deleted_at field with time zone |
| $table->string('name', 100); | equivalent to with length VARCHAR |
| $table->text('description'); | equivalent to TEXT |
| $table->time('sunrise'); | equivalent to TIME |
| $table->timeTz('sunrise'); | equivalent to with time zone of TIME |
| $table->timestamp('added_on'); | equivalent to TIMESTAMP |
| $table->timestampTz('added_on'); | equivalent to with time zone TIMESTAMP |
| $table->timestamps(); | equivalent to nullable created_at and updated_at TIMESTAMP |
| $table->timestampsTz(); | equivalent to nullable with timezone created_at and updated_at TIMESTAMP |
| $table->tinyIncrements('id'); | equivalent to auto increment UNSIGNED TINYINT |
| $table->tinyInteger('votes'); | equivalent to TINYINT |
| $table->unsignedBigInteger('votes'); | equivalent to UNSIGNED BIGINT |
| $table->unsignedDecimal('amount', 8, 2); | equivalent to with precision and base UNSIGNED DECIMAL |
| $table->unsignedInteger('votes'); | equivalent to UNSIGNED INT |
| $table->unsignedMediumInteger('votes'); | equivalent to UNSIGNED MEDIUMINT |
| $table->unsignedSmallInteger('votes'); | equivalent to UNSIGNED SMALLINT |
| $table->unsignedTinyInteger('votes'); | equivalent to UNSIGNED TINYINT |
| $table->uuid('id'); | equivalent to UUID |
| $table->year('birth_year'); | equivalent to YEAR |
## Modify fields
### Prerequisites
Make sure to add the `doctrine/dbal` dependency to the `composer.json` file before modifying the fields. The Doctrine DBAL library is used to determine the current state of a field and create the SQL query required to make the specified adjustments to that field:
> Only the following field types can be "modified": bigInteger, binary, boolean, date, dateTime, dateTimeTz, decimal, integer, json, longText, mediumText, smallInteger, string, text, time, unsignedBigInteger, unsignedInteger and unsignedSmallInteger.
The migrator automatically generates a reasonable index name, and each index method accepts an optional second argument to specify the name of the index:
You can drop an index in the following way. By default, the migration program will automatically concatenate the database name, the field name of the index, and the index type as the name. Examples are as follows:
You can also pass an array of fields to the `dropIndex` method and the migrator will generate an index name based on the table name, field and key type:
We can also create foreign key constraints at the database layer through the `foreign`, `references`, `on` methods. For example, let's let the `posts` table define a `user_id` field that references the `id` field of the `users` table:
You can drop foreign keys with the `dropForeign` method. Foreign key constraints are named in the same way as indexes, followed by a `_foreign` suffix: