Migrations
How migrations work
Once you get into production you'll need to synchronize model changes into the database. Typically, it is unsafe to use synchronize: true
for schema synchronization on production once you get data in your database. Here is where migrations come to help.
A migration is just a single file with sql queries to update a database schema and apply new changes to an existing database.
Let's say you already have a database and a post entity:
And your entity worked in production for months without any changes. You have thousands of posts in your database.
Now you need to make a new release and rename title
to name
. What would you do?
You need to create a new migration with the following SQL query (postgres dialect):
Once you run this SQL query your database schema is ready to work with your new codebase. TypeORM provides a place where you can write such sql queries and run them when needed. This place is called "migrations".
Creating a new migration
Pre-requisites: Installing CLI
Before creating a new migration you need to setup your data source options properly:
Here we setup two options:
"migrationsTableName": "migrations"
- Specify this option only if you need the migration table name to be different from"migrations"
."migrations": [/*...*/]
- list of migrations that need to be loaded by TypeORM
Once you setup the connection options you can create a new migration using CLI:
Here, PostRefactoring
is the name of the migration - you can specify any name you want. After you run the command you can see a new file generated in the "migration" directory named {TIMESTAMP}-PostRefactoring.ts
where {TIMESTAMP}
is the current timestamp when the migration was generated. Now you can open the file and add your migration sql queries there.
You should see the following content inside your migration:
There are two methods you must fill with your migration code: up
and down
. up
has to contain the code you need to perform the migration. down
has to revert whatever up
changed. down
method is used to revert the last migration.
Inside both up
and down
you have a QueryRunner
object. All database operations are executed using this object. Learn more about query runner.
Let's see what the migration looks like with our Post
changes:
Running and reverting migrations
Once you have a migration to run on production, you can run them using a CLI command:
typeorm migration:create
and typeorm migration:generate
will create .ts
files, unless you use the o
flag (see more in Generating migrations). The migration:run
and migration:revert
commands only work on .js
files. Thus the typescript files need to be compiled before running the commands. Alternatively you can use ts-node
in conjunction with typeorm
to run .ts
migration files.
Example with ts-node
:
Example with ts-node
in ESM projects:
This command will execute all pending migrations and run them in a sequence ordered by their timestamps. This means all sql queries written in the up
methods of your created migrations will be executed. That's all! Now you have your database schema up-to-date.
If for some reason you want to revert the changes, you can run:
This command will execute down
in the latest executed migration. If you need to revert multiple migrations you must call this command multiple times.
Faking Migrations and Rollbacks
You can also fake run a migration using the --fake
flag (-f
for short). This will add the migration to the migrations table without running it. This is useful for migrations created after manual changes have already been made to the database or when migrations have been run externally (e.g. by another tool or application), and you still would like to keep a consistent migration history.
This is also possible with rollbacks.
Transaction modes
By default, TypeORM will run all your migrations within a single wrapping transaction. This corresponds to the --transaction all
flag. If you require more fine grained transaction control, you can use the --transaction each
flag to wrap every migration individually, or the --transaction none
flag to opt out of wrapping the migrations in transactions altogether.
In addition to these flags, you can also override the transaction behavior on a per-migration basis by setting the transaction
property on the MigrationInterface
to true
or false
. This only works in the each
or none
transaction mode.
Generating migrations
TypeORM is able to automatically generate migration files with schema changes you made.
Let's say you have a Post
entity with a title
column, and you have changed the name title
to name
. You can run following command:
If you encounter any error, it require you have the path to migration name and data source. You can try this option
And it will generate a new migration called {TIMESTAMP}-PostRefactoring.ts
with the following content:
Alternatively you can also output your migrations as Javascript files using the o
(alias for --outputJs
) flag. This is useful for Javascript only projects in which TypeScript additional packages are not installed. This command, will generate a new migration file {TIMESTAMP}-PostRefactoring.js
with the following content:
See, you don't need to write the queries on your own. The rule of thumb for generating migrations is that you generate them after each change you made to your models. To apply multi-line formatting to your generated migration queries, use the p
(alias for --pretty
) flag.
DataSource option
If you need to run/revert/generate/show your migrations use the -d
(alias for --dataSource
) and pass the path to the file where your DataSource instance is defined as an argument
Timestamp option
If you need to specify a timestamp for the migration name, use the -t
(alias for --timestamp
) and pass the timestamp (should be a non-negative number)
You can get a timestamp from:
Using migration API to write migrations
In order to use an API to change a database schema you can use QueryRunner
.
Example:
Returns all available database names including system databases.
database
- If database parameter specified, returns schemas of that database
Returns all available schema names including system schemas. Useful for SQLServer and Postgres only.
tableName
- name of a table to be loaded
Loads a table by a given name from the database.
tableNames
- name of a tables to be loaded
Loads a tables by a given names from the database.
database
- name of a database to be checked
Checks if database with the given name exist.
schema
- name of a schema to be checked
Checks if schema with the given name exist. Used only for SqlServer and Postgres.
table
- Table object or name
Checks if table exist.
table
- Table object or namecolumnName
- name of a column to be checked
Checks if column exist in the table.
database
- database nameifNotExist
- skips creation iftrue
, otherwise throws error if database already exist
Creates a new database.
database
- database nameifExist
- skips deletion iftrue
, otherwise throws error if database was not found
Drops database.
schemaPath
- schema name. For SqlServer can accept schema path (e.g. 'dbName.schemaName') as parameter. If schema path passed, it will create schema in specified databaseifNotExist
- skips creation iftrue
, otherwise throws error if schema already exist
Creates a new table schema.
schemaPath
- schema name. For SqlServer can accept schema path (e.g. 'dbName.schemaName') as parameter. If schema path passed, it will drop schema in specified databaseifExist
- skips deletion iftrue
, otherwise throws error if schema was not foundisCascade
- Iftrue
, automatically drop objects (tables, functions, etc.) that are contained in the schema. Used only in Postgres.
Drops a table schema.
table
- Table object.ifNotExist
- skips creation iftrue
, otherwise throws error if table already exist. Defaultfalse
createForeignKeys
- indicates whether foreign keys will be created on table creation. Defaulttrue
createIndices
- indicates whether indices will be created on table creation. Defaulttrue
Creates a new table.
table
- Table object or table name to be droppedifExist
- skips dropping iftrue
, otherwise throws error if table does not existdropForeignKeys
- indicates whether foreign keys will be dropped on table deletion. Defaulttrue
dropIndices
- indicates whether indices will be dropped on table deletion. Defaulttrue
Drops a table.
oldTableOrName
- old Table object or name to be renamednewTableName
- new table name
Renames a table.
table
- Table object or namecolumn
- new column
Adds a new column.
table
- Table object or namecolumns
- new columns
Adds a new column.
table
- Table object or nameoldColumnOrName
- old column. Accepts TableColumn object or column namenewColumnOrName
- new column. Accepts TableColumn object or column name
Renames a column.
table
- Table object or nameoldColumn
- old column. Accepts TableColumn object or column namenewColumn
- new column. Accepts TableColumn object
Changes a column in the table.
table
- Table object or namechangedColumns
- array of changed columns.oldColumn
- old TableColumn objectnewColumn
- new TableColumn object
Changes a columns in the table.
table
- Table object or namecolumn
- TableColumn object or column name to be dropped
Drops a column in the table.
table
- Table object or namecolumns
- array of TableColumn objects or column names to be dropped
Drops a columns in the table.
table
- Table object or namecolumnNames
- array of column names which will be primary
Creates a new primary key.
table
- Table object or namecolumns
- array of TableColumn objects which will be updated
Updates composite primary keys.
table
- Table object or name
Drops a primary key.
table
- Table object or nameuniqueConstraint
- TableUnique object to be created
Creates new unique constraint.
Note: does not work for MySQL, because MySQL stores unique constraints as unique indices. Use
createIndex()
method instead.
table
- Table object or nameuniqueConstraints
- array of TableUnique objects to be created
Creates new unique constraints.
Note: does not work for MySQL, because MySQL stores unique constraints as unique indices. Use
createIndices()
method instead.
table
- Table object or nameuniqueOrName
- TableUnique object or unique constraint name to be dropped
Drops an unique constraint.
Note: does not work for MySQL, because MySQL stores unique constraints as unique indices. Use
dropIndex()
method instead.
table
- Table object or nameuniqueConstraints
- array of TableUnique objects to be dropped
Drops an unique constraints.
Note: does not work for MySQL, because MySQL stores unique constraints as unique indices. Use
dropIndices()
method instead.
table
- Table object or namecheckConstraint
- TableCheck object
Creates new check constraint.
Note: MySQL does not support check constraints.
table
- Table object or namecheckConstraints
- array of TableCheck objects
Creates new check constraint.
Note: MySQL does not support check constraints.
table
- Table object or namecheckOrName
- TableCheck object or check constraint name
Drops check constraint.
Note: MySQL does not support check constraints.
table
- Table object or namecheckConstraints
- array of TableCheck objects
Drops check constraints.
Note: MySQL does not support check constraints.
table
- Table object or nameforeignKey
- TableForeignKey object
Creates a new foreign key.
table
- Table object or nameforeignKeys
- array of TableForeignKey objects
Creates a new foreign keys.
table
- Table object or nameforeignKeyOrName
- TableForeignKey object or foreign key name
Drops a foreign key.
table
- Table object or nameforeignKeys
- array of TableForeignKey objects
Drops a foreign keys.
table
- Table object or nameindex
- TableIndex object
Creates a new index.
table
- Table object or nameindices
- array of TableIndex objects
Creates a new indices.
table
- Table object or nameindex
- TableIndex object or index name
Drops an index.
table
- Table object or nameindices
- array of TableIndex objects
Drops an indices.
tableName
- table name
Clears all table contents.
Note: this operation uses SQL's TRUNCATE query which cannot be reverted in transactions.
Enables special query runner mode in which sql queries won't be executed, instead they will be memorized into a special variable inside query runner. You can get memorized sql using getMemorySql()
method.
Disables special query runner mode in which sql queries won't be executed. Previously memorized sql will be flushed.
Flushes all memorized sql statements.
returns
SqlInMemory
object with array ofupQueries
anddownQueries
sql statements
Gets sql stored in the memory. Parameters in the sql are already replaced.
Executes memorized up sql queries.
Executes memorized down sql queries.
Last updated