3 ms·
> Did anybody liked writing data migration? Try explaining value of table migration to some Product Manager of early startup :-). data integrity isn't good eno
by camus2 9y ago
> Did anybody liked writing data migration? Try explaining value of table migration to some Product Manager of early startup :-).
data integrity isn't good enough for a product manager? It's like saying "statically typed languages aren't worth the effort, do everything in JavaScript".
Furthermore, MongoDB or not, an application in development needs DB migrations. I don't believe one second you can change all your classes or structs and pretend like MongoDB will magically update your previous documents and collections to the current state of your application.
- threeseed 9y agoOf course not. MongoDB is not magic. But one huge advantage of MongoDB is that it is schemaless. And so you have a lot more options for how you migrate documents. For example you can move all of the data under a particular key e.g. "v1" and allow two schemas to co-exist within the one document. Significantly less risky than running migration scripts or doing a alter schema in production.
- amarkov 9y agoBut it's just as easy and just as safe to allow two schemas to co-exist within the same database. If you follow the necessary steps for a risk-free data migration, having both schemas coexist simultaneously and doing gradual switchovers, both models are going to be comparably difficult. What schemaless lets you do is hide your risk better by disguising those steps. "db.table.update({$set: ...}, {multi: true})" looks friendly, but it's the same terrifying operation as running DROP TABLE A the instant you're done generating table B. And it looks easier, but that's because your code's beliefs about which schema it's reading from are hidden and implicit.