Repository navigation
What's the best practice for adding db-migrate to a project with an existing database? #828
Description
I'm submitting a...
- Bug report
- Feature request
- Question
Current behavior
db-migrate works great if you're greenfielding a new project. but my project is already live and has a database with existing schema and data. what's the recommended approach for adding db-migrate to this project?
related #604 (comment)
Expected behavior
I expect clear guidance\docs on integrating db-migrate with live projects that already have schema and data. Alternatively, I expect that if db-migrate isn't suitable for projects that already have schema and data, the docs\README make that clear instead.
Minimal reproduction of the problem with instructions
NA
What is the motivation / use case for changing the behavior?
NA
Environment
db-migrate version: latest
Additional information:
- Node version: LTS
- Platform: linux
Others:
Activity
klansser commentedon Jun 27, 2024
I've simply created innit-up.sql with current schema creation by
CREATE TABLE IF NOT EXISTS.File innit-down.sql is empty and doesn't drop any table.
murderteeth commentedon Jun 27, 2024
tu! yeah that's what I did too https://github.com/murderteeth/kong?tab=readme-ov-file#how-to-baseline-a-production-db-in-flight
wzrdtales commentedon Jun 27, 2024
That is a thing you can do yes. I wrote before I started working on db-migrate itself, a tool to convert an existing db to migrations (https://github.com/wzrdtales/node-ultimate-migrate) . I do not really recommend using it, and it anyway only support mysql/mariadb, though. A SQL file is a way to start off an existing state, the pain of migrating to migrations is big, that is why in the best case you do it from the beginning. The tool I wrote back in the days in the frustration of having to get a legacy project into migrations.
The downside of your SQL approach. Db-migrate does support stateful atomic migrations in its v2 definition, those you couldn't really use without defining the existing schema. However, v2 migrations (#508, examples are in the text here #627 (comment)) are something we use internally everywhere, but it is not strictly released yet though, so that is probably not important to you right now. With v1 migrations which are just explicit and have no real intelligence in them your SQL file approach will not result in any problems.