Is ORM necessary for Mongodb when the structure of collection changes quickly?

Question

I am a Java user. Recently, I need to build a web project for MongoDB. Based on software requirement, we have to change the structure of collection frequently, that means there is no permanent structure. After trying several Java Object Document Mapper for MongoDB, like Morphia and Spring data for MongoDB, I find that those framework can not support changes in collection structure. We define the parameters in class in advance, but what if those parameters are no longer exist in collection after an update or some new parameters shall be added to the class file?

My question is that is ORM necessary when the structure of collection changes. Are there any solutions to this situation?

Answer 1

It depends a little on what you mean by these frameworks not support changes in collection structure. If you've already settled on using Java as your development language, you've already committed to a fairly rigid schema in some ways. You could model your business types as Maps and then you're just stuffing things in Maps by name and you don't really care what the types are or the underlying structure. At least until you pull them out and try to use them. You could manually convert your Java objects to the various driver types (DBObject or Document) but this can be a fair bit of work and prone to errors as things evolve.

Java all but forces you to think about types and structure for good reason. As your application evolution sprints headlong from one schema to the next, Java's type system helps find cases where you forgot to update your code to match the new structures. And any half decent IDE will help you refactor around these new structures.

Similarly, using and ODM like Morphia or spring-data will help you get your data in and out of the database. Depending on how your development cycle goes, you might have data in the database using the old schema but this is a problem separate from whether you use an ODM or not. In fact, using an ODM can help you find places in the code and application where you need to take a look at migrating to the new schema.

At the database level, you'll need to do migrations in any case. This is often done via scripts you can via the mongo shell but can certainly be done via Java and the driver as well. It's that using the entity classes via the ODM to migrate your data, while not impossible, can certainly be complicated but these issues are, again, largely orthogonal to the decision to use an ODM or not.

Having built a number of applications using ODMs (and ORMs on RDBMS systems), I don't find them overly restricting when evolving the schema. The ultimate headaches are really about massaging data in to the new shape. Using an ODM makes migrating business code to the new schema almost trivial, really.

Ultimately, it's a matter of preference and comes down to what you and your team are comfortable with. Personally, I'd much rather use an ODM than rely on Map based business entities or manually shuttling data in and out of the driver.