4 ms·

Having taken a ruby app through mysql => mongodb => mysql there were several reasons that I wouldn't recommend mongodb as a goto solution for persistence. 1) Y

by ollysb 15y ago

Having taken a ruby app through mysql => mongodb => mysql there were several reasons that I wouldn't recommend mongodb as a goto solution for persistence. 1) Your tests have to be document aware. Models that are embedded within a document are very difficult to test in isolation from the rest of the document. You need to build the whole document before you can test any persistence related functionality. 2) Refactoring relationships is difficult. When you start building an app you don't know how the model is going to turn out. With a relational model that's fine, you can add/remove relationships easily. With documents your models are organised into hierarchies that they have to be aware of. The code that handles this hierarchy is incredibly brittle. If you move a model from one document to another, or just it's own document, you're going to have lots of code to fix. Maybe it's a case of needing some new refactoring patterns, but rest assured, they'll be far more complicated than refactoring patterns for relational stores. 3) Mongoid and the uncanny valley. It looks like activerecord, but I spent an inordinate amount of time working around bugs and methods that you expected to be there that just weren't. Admittedly this was before the stable version was released(the recommended version at the time) so things may look significantly better now.

dolinsky 15y ago
I think you're talking about a few different points here that aren't necessarily related. Persistence (which is available in MongoDB) has nothing to do with testing of a model (a single document inside a collection). Some actually see that as an advantage of using a schemaloose (yes I just made that up) storage like MongoDb. I don't need to have a whole document defined in order to test the functionality of an embeded object in that document. Yes, you're relying on the application alone to enforce the model, but that's a trade off made up front regardless. As for modeling and the cost of refactoring, I think it depends on more than just the storage facility you're using. The code that handles your modeling in MongoDB is only as brittle or robust as you choose, same as a SQL solution. Yes, it helps if you think more up front about how you are going to query the data that you store using MongoDB as this will help to minimizing refactoring later on. However, I think the pain associated with moving part of a table to another / new table in SQL is no less painful than moving an embedded object or other data structure around in MongoDB. In both cases you're moving data and affecting changes in your application.
gregwebs 15y ago
Thanks for sharing your experience. I think 3) is better now that version 2.0 of Mongoid has been released (and is stable). The developer I am working with complained about earlier versions also. I ported hundreds of lines of ActiveRecord model code, and it mostly just worked. I am not really experiencing pain around 1) either. I am using factory girl and find it easy to build any required data. It could actually be beneficial that you must focus on creating a group of properly linked objects. I have run into trouble before with messed up/difficult to create object graphs in ActiveRecord tests. 2) Is a good point I am now mentioning in the post. I will let others argue with you about its severity :)
- ollysb 15y ago
  I probably need to do some code examples to illustrate the pain points I was experiencing for 1). When I migrated back to ActiveRecord I kept the same model initially and found that I was able to significantly simplify the tests. My main difficulty was with methods that called save on embedded models. I suppose I could have stubbed those calls out but I generally prefer to test the integration with the db. Yeah, I know it's not a pure unit test but I find this is generally the more pragmatic approach. I should say I think mongodb/mongoid can be very useful. My opinion so far though is that it's most effective as a performance optimisation strategy for a stable application.

by ollysb 15y ago

dolinsky 15y ago

I think you're talking about a few different points here that aren't necessarily related. Persistence (which is available in MongoDB) has nothing to do with testing of a model (a single document inside a collection). Some actually see that as an advantage of using a schemaloose (yes I just made that up) storage like MongoDb. I don't need to have a whole document defined in order to test the functionality of an embeded object in that document. Yes, you're relying on the application alone to enforce the model, but that's a trade off made up front regardless. As for modeling and the cost of refactoring, I think it depends on more than just the storage facility you're using. The code that handles your modeling in MongoDB is only as brittle or robust as you choose, same as a SQL solution. Yes, it helps if you think more up front about how you are going to query the data that you store using MongoDB as this will help to minimizing refactoring later on. However, I think the pain associated with moving part of a table to another / new table in SQL is no less painful than moving an embedded object or other data structure around in MongoDB. In both cases you're moving data and affecting changes in your application.

gregwebs 15y ago

Thanks for sharing your experience. I think 3) is better now that version 2.0 of Mongoid has been released (and is stable). The developer I am working with complained about earlier versions also. I ported hundreds of lines of ActiveRecord model code, and it mostly just worked. I am not really experiencing pain around 1) either. I am using factory girl and find it easy to build any required data. It could actually be beneficial that you must focus on creating a group of properly linked objects. I have run into trouble before with messed up/difficult to create object graphs in ActiveRecord tests. 2) Is a good point I am now mentioning in the post. I will let others argue with you about its severity :)

ollysb 15y ago
I probably need to do some code examples to illustrate the pain points I was experiencing for 1). When I migrated back to ActiveRecord I kept the same model initially and found that I was able to significantly simplify the tests. My main difficulty was with methods that called save on embedded models. I suppose I could have stubbed those calls out but I generally prefer to test the integration with the db. Yeah, I know it's not a pure unit test but I find this is generally the more pragmatic approach. I should say I think mongodb/mongoid can be very useful. My opinion so far though is that it's most effective as a performance optimisation strategy for a stable application.