wildebeest | Database migration for Sequelize | Data Migration library

wildebeest is a TypeScript library typically used in Migration, Data Migration, PostgresSQL applications. wildebeest has no bugs, it has no vulnerabilities and it has low support. You can download it from GitHub.

(This repo and its docs are a work in progress). When using Sequelize as your ORM, you still need to write some database migrations manually. For example, when adding a new column that is non-null, one often needs to calculate the initial value based on existing database rows. Keeping the Postgres schema in sync with the Sequelize schema defined in code is painful. The schema in Postgres should be thought of as the "base truth", but it comes at the cost of being able to dynamically define the schema in code. One must repeatedly compare the code against the remote database's state. To simplify this process, we have a database Model class that wraps all database tables we define. This Model class has a method, checkIfSynced, that will compare the code definition of that Sequelize model to the existing schema in Postgres. It will log anywhere it finds these definitions to be out of sync. In production mode, the server will call this function before starting up, and fail if the migrations have not been run. In development mode, the developer must go to localhost/migrate/sync to run this synchronization test. This route is also hit during the integration tests that run with npm run test, so a PR will not be able to merge if the database is not properly migrated. When writing migrations, you need to specify what will happen when the migration is run, "up" and "down" - forward and in reverse. Production systems will only ever run migrations in an up manner, where data is conserved and not lost. The down migrations are useful in development to be able to revert back to a previous database state. The preferred mechanism for writing migrations is to break each migration into small parts, and use configuration where possible, rather than actually writing both the up and down migrations manually. We currently have a variety of [migration-types]{@link module:migrationTypes} that simplify the process of writing migrations, and make the migration code more readable. See addColumns and removeColumns below for examples of migration-types. These migration types can be configured in the same way, because they are actually the same migration, but up and down are swapped.