... | ... | @@ -373,7 +373,7 @@ If migrations have yet to be configured, then the migration system will: |
|
|
* Generate a migrations configuration `migrations.json`.
|
|
|
* Generate a year directory for the respective year.
|
|
|
* Generate a month directory for the respective month.
|
|
|
* Generate the migrations file `your-named-migration-xxx.ts`
|
|
|
* Generate the migrations file `mmddyyyy_your-named-migration.js`
|
|
|
|
|
|
Any future migrations which are generated will cause the migrator to verify all aspects of the migration system's configuration, and ensure each exists and is complete. Pending this, the migrator will generate a new migration file.
|
|
|
|
... | ... | @@ -385,21 +385,21 @@ To apply any pending migrations all that is required - assuming all requirements |
|
|
nkm migrate
|
|
|
```
|
|
|
|
|
|
This will cause the system to read the available migrations as well as any applied migrations found in the migrations table. Each pending migration is applied - post being queued for process management - and flagged as completed in the migration table.
|
|
|
This will cause the system to read the available migrations, as well as any applied migrations found in the migrations table. Each pending migration is applied - post being queued for process management - and flagged as completed in the migration table.
|
|
|
|
|
|
#### Reverting Migrations
|
|
|
|
|
|
To revert a migration, it is required that it was first applied. Assuming it was, you can step back through the applied migrations any number of times required to revert the migration state to that which is desired.
|
|
|
|
|
|
```bash
|
|
|
nkm migrate --step-back <#-of-steps>
|
|
|
nkm migrate --step-back [#-steps]
|
|
|
```
|
|
|
|
|
|
The number of steps supplied, is the number of migrations - in reverse applied order - that the migrator will revert.
|
|
|
|
|
|
#### How Migrations Work
|
|
|
|
|
|
The migration system uses a table that stores any migrations which have been successfully applied. It stores a record of any migrations that have been applied inside of said table, so th at regardless of what migrations exist on disk - migrations would never be applied twice unless there was a serious mismanagement of migration files.
|
|
|
The migration system uses a table that stores a record of any migrations which have been successfully applied. It stores this record, so that regardless of what migrations exist on disk; migrations would never be applied twice with out there being a serious mismanagement of migration files.
|
|
|
|
|
|
##### Migration Paths
|
|
|
|
... | ... | @@ -407,7 +407,7 @@ There may be a version associated with a particular migration path. This version |
|
|
|
|
|
Let's say that there is an initial version 1 seed, and 20 subsequent version 1 migrations: Developers following said migration path will continue applying migrations as they become available.
|
|
|
|
|
|
Next, let's say that a version 2 seed becaomes available which consolidates the version 1 seed and all of version 1's subsequent migrations. New developers to said project will run the version 2 seed (with out knowing so, the migration system will detect and decide upon this), and then follow along with any version 2 migrations that may subsequently become available.
|
|
|
Next, let's say that a version 2 seed becomes available which consolidates the version 1 seed and all of version 1's subsequent migrations. New developers to said project will run the version 2 seed (with out knowing so, the migration system will detect and decide upon this), and then follow along with any version 2 migrations that may subsequently become available.
|
|
|
|
|
|
Developers on the version 1 migration path will continue on the version 1 path until they've reached its end, and then begin along the version 2 path from its first migration - bypassing the version 2 seed.
|
|
|
|
... | ... | |