Creating 'Migrating to a specific version' and 'Executing down migrations' sub sections.
All checks were successful
Deploy Greenlight API / deploy (push) Successful in 1m0s
All checks were successful
Deploy Greenlight API / deploy (push) Successful in 1m0s
This commit is contained in:
35
README.md
35
README.md
@@ -94,6 +94,41 @@ The **version** column here indicates that our migration files up (and including
|
||||
|
||||
You can run the **\d** meta command on the **movies** table to see the structure of the table and confirm the **CHECK** constraints were created correctly.
|
||||
|
||||
### Migrating to a specific version
|
||||
|
||||
As an alternative to looking at the **schema_migrations** table, if you want to see which migration version your database is currently on, you can run the **migrate** tool's **version** command like so :
|
||||
|
||||
```bash
|
||||
$ migrate -path=./migrations -database=$EXAMPLE_DSN version
|
||||
2
|
||||
```
|
||||
|
||||
You can also migrate up or down to a specific version by using the **goto** command:
|
||||
|
||||
```bash
|
||||
$ migrate -path=./migrations -database=$EXAMPLE_DSN goto 1
|
||||
```
|
||||
|
||||
### Executing down migrations
|
||||
|
||||
You can use the down command to roll-back by a specific number of migrations. For example, to rollback the _most recent migration_, you would run :
|
||||
|
||||
```bash
|
||||
$ migrate -path=./migrations -database=$EXAMPLE_DSN down 1
|
||||
```
|
||||
Generally, prefer **goto** command to perform roll-backs (as it's more explicit about the target version) and reserve use of the **down** command for rolling-back _all migrations_, like so:
|
||||
|
||||
```bash
|
||||
$ migrate -path=./migrations -database=$EXAMPLE_DSN down
|
||||
Are you sure you want to apply all down migrations? [y/N]
|
||||
y
|
||||
Applying all down migrations
|
||||
2/d create_bar_table (39.38729ms)
|
||||
1/d create_foo_table (59.29829ms)
|
||||
```
|
||||
|
||||
Another variant of this is the **drop** command, which will remove all tables from the database including the **schema_migrations** table - but the database itself will remain, [along with anything else that has been created](https://github.com/golang-migrate/migrate/issues/193) like sequences and enums. Because if this, using **drop** can leave your database in a messy and unknown state, and it's generally better to stick with the **down** command if you want to roll back everything.
|
||||
|
||||
## Additional Information
|
||||
|
||||
### How different Go Types are encoded
|
||||
|
||||
Reference in New Issue
Block a user