Hacker News Reader

Comment by zerosanity | Hacker News Reader

I really wish they would straighten out their documentation. I've only looked a few times but it seems very conditional in the description of features like replication sets, etc. I think they should have it organized like the MySQL site has it. E.g. view 5.0 documentation here, or 5.1 here, etc.

The way it is now I couldn't tell you right away what version supports what just by glancing at the docs for a minute.

View on HN

Thanks for mentioning this. We're just now starting on a massive reorganization and rewrite of the docs. Look for some solid initial progress by mid-October.

I definitely concur with the statement on organizing by release cycle (or perhaps using the PHP convention of showing deprecation and support version information for different calls).

I recently ran into issues with replicaSet myself; finding it hard to locate documentation on using user-based authentication. It boiled down to me eventually locating the necessary info on the Master-Slave page for ensuring I did a db.addUser() on the slave's local db. All in all, I'm much looking forward to a rewrite of the documentation.

And I hope they spend some resources in making MongoDB a first class citizen for Django / Rails projects. Like a complete drop in replacement for MySQL. It's already pretty close. Life would be so good if you could use MongoDB as the default for any project and all gems/apps would just work with it. Goodbye migrations, hello autosharding.

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.

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.

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

>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.

Reply on news.ycombinator.com