How to Automate Database Migrations in MongoDB Using Nodejs

How to Automate Database Migrations in MongoDB Using Nodejs(101node.io)

1 points by banna2 7 years ago | 3 comments

stephenr 7 years ago |

This is why I can’t take mongodb or nodejs seriously.

First off: you need two separate third party packages to achieve `mkdir -p` and `rm -rf`? How is that not a giant red flag for anyone reading this?

Secondly: this is exactly why I don’t buy the “having to define a schema slows down dev, so we can’t use sql”.

You clearly do have a schema, it’s just that it exists almost solely in your application code (i hope you at least have indexes in the db?). But now because your schema is changing rapidly you need a way to update the schemaless documents to meet... the new schema.

So now you’re back writing more fucking javascript to update the schema of your documents that are “schemaless” because your schema changes so often.

Did I miss anything?

murukesh_s 7 years ago | |

You have good points. But as a person who felt like heaven when switched from Go back to Node.j to write a migration tool for migrating data from two different data sources which was frustrating in Go, I don't know what to say.. Node.js is good, it's very fast and with Typescript, it reduces a lot of unwanted bugs as well. May be it's me, but Javascript flows for me, but not other languages. I have reasonable knowledge in Java, very minimal experience in Go, PHP and Python. For me Node.js is the sweet spot. It's almost as fast as Go (way faster than Python and Ruby) and almost as productive as Python plus you don't need the context switch when you move from Frontend to Backend.. It's natively async which other languages are playing catchup. It's single thread model, though can feel limited, is god send and simple to reason especially when you get to debug thread introduced bugs in a million line Java stack which only occur in production. IMO with some multi process hack it's almost as capable as Java or Go.

Regarding MongoDB, it also serves a similar purpose (faster development). There are tradeoffs and if you are experienced in SQL you may feel irritated when reading it's shortcomings, it's understandable.

stephenr 7 years ago | | |

My issue with both is basically that the things people claim to be 'better' about both are really not, as evidenced by the work required to compensate for those 'features'.

No schema? Great I can just keep changing my app's code. Oh wait but now I need to either handle migrations in my app or run a separate script to migrate everything. So there is a schema, it just isn't enforced by the database layer, and thus can't be migrated by the database layer.

Single threaded-async? Great, now I can just run a single process and handle heaps of requests. Oh, but also, can someone work on a way to not have a million nested callbacks? Yes, that's right, we basically want to be able to write code that will run sequentially, regardless of the 'event loop'.

I'm not against alternatives to SQL databases. I think LDAP is a great example of a non-SQL data store, that still has a schema, and it's proven to work in huge environments.

I'm not fixed to a single specific language either, and I even write Javascript sometimes, but I feel like a lot of the time, it's used in spite of it's characteristics, not because of them.