migrate, status, rollbackmigrax generate writes migrations, and three commands handle the rest: status shows what
the database has, migrate applies what is missing, and rollback undoes it. This article
goes through each one on a real project. It also covers what a rollback can and can't bring
back, and what happens when someone edits a migration that already ran.
Renames are where generated migrations usually go wrong. When a field changes from name to
fullName, the database only sees one column disappear and another appear. A tool that just
compares the two schemas drops the old column, and every value in it, then adds an empty new
one.
Migrax notices when a change looks like a rename. In a terminal it asks you. In CI, where no one can answer, it refuses to write a migration that would lose the data. This article shows both cases for a column and for a table, and how to undo a rename.
Your JPA entities already describe the schema you want. Writing the same change again by hand as SQL is slow and easy to get wrong. Migrax compares your entities with the last state you committed and writes the SQL migration for you, along with a rollback script. You review the SQL, commit it, and apply it.
This article walks through that loop on a small project: create the first tables, add a column, and catch a missing migration in CI.