[TylerE]

I don't really think that's desirable. Trying to make a document database pretend it's a relational database may work "ok" for simple things, but when you have code that expects to do things that practical in SQL (think: joins, etc) it'll all end in tears.

[dasil003]

I think the point was that you should be able to flip a switch and get mongo in a fully functional Rails stack just as easily as you flip a switch and get mysql (sqlite being the default).

FWIW, I agree shoehorning mongo into a RDBMS role is a bad idea, but at the same time, devs who don't understand SQL are shoehorning all kinds of horrendous code into their ActiveRecord apps anyway. I've long criticized many NoSQL advocates (the extreme type who say SQL is dead) as simply being ignorant of the value of SQL and throwing the baby out with the bathwater. As much as I stand by that sentiment, it doesn't mean Mongo doesn't have a viable use case as a primary data store, and if you know what you're doing you shouldn't have to wrestle with Rails to make proper use of Mongo.

[JonnieCache]

>I think the point was that you should be able to flip a switch and get mongo in a fully functional Rails stack just as easily as you flip a switch and get mysql (sqlite being the default).

Mongoid, the premier mongodb rails adapter, has fully functioning model generators and its API is built on ActiveModel, the same as Rails' own ActiveRecord. Thus it is fully compatibile out of the box with the majority of other rails components, such as form builders and authentication systems.

It doesn't really get any more 'flip a switch' than that, even in the world of rails. Since 3.0 rails has been decoupled to the extent that other db adapters etc exist pretty much on an even footing with the rails defaults.

EDIT: apparently the mongomapper adapter also uses activemodel these days.

[TylerE]

That would be sane. It would also NOT mean "all gems/app just work with it", which is what GP said.