denodb
denodb copied to clipboard
eveningkid
Is there a recommended path to handling database migrations?
I probably missed it in the docs, but I was curious about how the library would handle an added or removed field on a model. Does db.sync always make sure the fields match in the db? I can imagine this being great for development lifecycle early in a project but would become dangerous in a longer living application and a more delicate migration path would be desired.
Hey John,
Actually, I am very glad you're raising this question because this is something I have been thinking about recently.
db.sync will only apply the schema you defined if it does not exist in your database, following the SQL naming convention (or keeping it as it is if you're using mongo).
You are right, in the long term, migrations are important. I don't really have any preference if I'm honest on how to go with migrations for this project. I see different ways of doing things with other frameworks.
What's your take on that? How would you picture this? I think we can just keep this very open before getting to work on it. How would you want to make database migrations ideally? :)
I will wait on you, I just want to get things right from a user perspective.
Keep in touch
Hi both,
Great question and important to resolve in considering denodb for production usage. I agree that development vs production approach for sync would look different. Prior experience with software vendors is that database columns remain even if no longer used - in case of customer usage such as historic reporting.
Production
- add new columns only
- resize columns only if larger
Development
- data preserved where possible i.e. if column changes size, don't drop/add use alter table column
- drop columns if no longer include in schema
Also I would think that default option is that denodb operates in production mode and new option (supplied by new database ?) to enforce development mode.
Well, i came to this discussion because I was thinking of using deno in one of my microservices, wich uses postgres (I really dont like sequelize), but migration is really important when talking about relational databaseses, I will keep an eye on this post.
Yeah I’m still thinking about it. With ORMs having an “autosync” feature is really nice, but fairly complex to build and also sometimes undesirable.
On the other hand I’ve never found a great way to run custom migration scripts with an ORM as it puts a lot more burden on the end user to know what types of data structures the ORM uses under the hood which is also undesirable.
Not to mention there’s the whole concept of Postgres extensions which should absolutely be supported and when done wrong can be quite painful. Maybe starting with the model definition having a “requiredExtensions” field? Maybe take a TypeORM style approach where once the model is in a complete form we could auto generate a migration script and tap into something like the db-migrate package?
These are just some initial thoughts I have. Still more questions than answers but maybe it will spark something else.
On Tue, Jul 7, 2020 at 8:42 AM André [email protected] wrote:
Well, i came to this discussion because I was thinking of using deno in one of my microservices, wich uses postgres (I really dont like sequelize), but migration is really important when talking about relational databaseses, I will keep an eye on this post.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/eveningkid/denodb/issues/58#issuecomment-654829689, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFI3Y3KKFLQQ7MCO7DSLBLTR2MJ25ANCNFSM4OBXKUGQ .
"there’s the whole concept of Postgres extensions which should absolutely be supported and when done wrong can be quite painful"
For this time, maybe handling then using pure sql would be the key
Yeah I agree with that.
On Mon, Jul 20, 2020 at 7:19 PM André [email protected] wrote:
"there’s the whole concept of Postgres extensions which should absolutely be supported and when done wrong can be quite painful"
For this time, maybe handling then using pure sql would be the key
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/eveningkid/denodb/issues/58#issuecomment-661429552, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFI3Y3PFAKWKF6QEPRBXYKTR4TGJRANCNFSM4OBXKUGQ .
I have found https://deno.land/x/nessie which would be a good tool to implement migrations for denodb
