3 ms·
You and you. You can use something like https://sqitch.org/ https://sqitch.org/ or https://flywaydb.org/ https://flywaydb.org/ or https://www.liquibase.org/ ht
by nextaccountic 6y ago
You and you.
You can use something like https://sqitch.org/ https://sqitch.org/ or https://flywaydb.org/ https://flywaydb.org/ or https://www.liquibase.org/ https://www.liquibase.org/ or https://github.com/rust-db/refinery https://github.com/rust-db/refinery where ideally your migrations should be written in plain sql (or a language that can output plain sql so you can see what it does). Then it's a matter of running those sql queries and knowing which migrations already happened.
- choeger 6y agoThe problem is: what is the single source of truth (TM) for the expected DB schema? An ORM will (hopefully) manage a meta table with all the information. If I work on a collaborative project, I might rely on an outdated table structure. So ideally, the app reflects the DB schema in some type-safe manner.
- valenterry 6y agoThere is no problem and the answer has already been giving: the migration library is the source of truth for the schema and that's it. There is just no ORM and if there is one it should not even have the permissions to execute any schema changes. > So ideally, the app reflects the DB schema in some type-safe manner. That's right! But there is no need to use an ORM for that. JooQ and other libraries (in my world it would be Quill https://getquill.io/ https://getquill.io/) do that for you.