Unfortunately there don’t appear to be a lot of users with experience using TypeORM with MongoDB, but it does look like you’ve asked in all of the right places to try to reach relevant audiences. Thanks for including the other links here – that will be useful for anyone else with a similar question.
I see that you have received at least one answer on your Stack Overflow question (although it looks like it took a +50 bounty to encourage responses). It seems that TypeORM currently ignores creating migrations for MongoDB, and the suggestion was to use a standalone migration tool instead.
MongoDB does not have a fixed schema or catalog to reference, and there is no strict requirement for all documents in a collection to have identical schema. You can enforce optional schema validation on inserts and updates using JSON Schema validation, but changes in schema validation rules do not affecting existing documents.
For larger deployments flexible schema can have significant performance benefits: you can change schema (or schema validation rules) without immediately rewriting all of the historical documents. However, the onus of handling schema variations is then pushed down to your application code.
If your use case requires a strictly consistent schema for all documents, you can still create more traditional migration scripts. However, there is some potential flexibility in choosing how to migrate documents. For example, you could choose to migrate documents in batches (perhaps based on some criteria like newest to oldest created) in order to control the impact on your MongoDB deployment’s working set or performance.
Thank you @Stennie_X, I hadn’t seen your response!
Yes, it took a +50 bounty, and the answer was a similar “write your own migration scripts each time” strategy.
Seems a bit error prone to me, but I guess you have the most control that way.
The story for TypeORM is so appealing though- put some typescript decorators on your data models and everything just falls into place!
Have some existing data you want to covered to a different data model? Just change the data model, generate and run a migration, and it all just works!
I guess there are some issues with it though- for example if you rename 2 string fields then how does it know which is which? what if they have different indexes, other decorators, etc.
The batching idea sort of makes sense in that you don’t have to bring the db server down at all and it doesn’t get a huge amount of traffic all at once potentially bottlenecking things when aded to the normal load. However, truly making your application(s) work correctly during this transition means you have to support both “versions” or the document, ie. adding additional arguably necessary branching logic making the code each time just a bit more complex and difficult to read and understand.
