The unbearable flexibility of schemalesness
Everybod hates Single Table Inheritance, right? MongoMapper has a similar concept, Single Collection Inheritance, but also a better alternative. MM provides, and in fact is mostly built with, a simple plugin system that is a thin wrapper around ruby's include. It includes the InstanceMethods, extends the ClassMethods, and provides a callback for configuring the model.
This better use of the ruby approach to grouping methods into modules becomes truly powerful when combined with the DataMapper pattern (which MongoMapper essentially implements) and a schemaless datastore like Mongo.
In the gist below I demonstrate using MongoMapper's plugin system to build aggregate models, in place of a pure single inheritance hierarchy with which it is fully compatible. You can couple this with composition by using your plug-in to add associations and associated proxy methods for them.
I think this flexibility is the real power of NoSQL: not "web-scale", which people have been doing with SQL for years, but defining your data type once, in your model, with the full dynamism of ruby. I was skeptical about key-value stores as a default storage engine for web apps, until very recently, and still think MySQL is the right answer for many people and projects. But my most recent client project uses MongoMapper, and as we started to refactor and DRY up the models, I finally saw how truly useful not being bound to a datastore's schema is.
Migrations? Yes, you don't get AR migrations. The 'proper' migrations, which only affect schema, are unneeded anyways, in a DataMapper. And data migrations are done wrong 99% of the time anyways, imo; pretending they are instantaneous is a mistake. In either AR or MM you should handle you data migrations more robustly, via code switches and async tasks to transform the data. If I get a chance to make this a talk, I may explore that more fully.
