

MongoDB 2.0 Released - meghan
http://blog.mongodb.org/post/10126837729/mongodb-2-0-released

======
kennu
I think I speak for everybody here when I say that 1.8 + 0.2 = 1.10.

~~~
Pewpewarrows
Sorry, but no. You seem to still be trapped in the ancient mindset that an
increment in the most significant version number must mean huge changes.
Instead, more often than not, it's merely a milestone signifying that all of
your intended features that you outlined in the previous major version's days
have been completed. So when 1.0 hits (or close to it), you define a bunch of
"must-haves" for 2.0, along with all the bugs and smaller improvements that
come up along the way. Now you can wait 18 months, only issuing security
patches for 1.0.x, and then deliver all of those features all at once with a
2.0 party. Or as each feature is complete, you release a new minor version
(1.1 for foo, 1.2 for bar, etc). Once you're able to scratch off the last of
your list for 2.0, you bump the version number up and call it a day, from
wherever you are along the 1.x line (be it 1.1 or 1.42). With sufficient
planning, you can manage to make it so that you never have to go into 1.xx
territory (with double digit minor version numbers). I'm sure I'm not alone in
finding 1.10 to be aesthetically ugly. If you have to, then by all means.
Avoid it if you can, but at the end of the day milestones should always be
your metric for release numbers.

Now in Mongo's case they might just be incrementing the major version number
for the hell of it. But I'm assuming they actually planned this out.

~~~
stingraycharles
_You seem to still be trapped in the ancient mindset that an increment in the
most significant version number must mean huge changes._

Isn't it more about personal preference rather than having an "ancient
mindset"?

------
samrat
I'm interested in learning more about MongoDB so that I can use it for web
apps. But some comments I've heard about it(especially here
[https://plus.google.com/111091089527727420853/posts/WQYLkopE...](https://plus.google.com/111091089527727420853/posts/WQYLkopE813))
seemed to discourage its use. Can someone explain to me why it is "criticized
by academics"? And what its pros/cons are?

~~~
bigethan
Anecdotally: Mongo is great for developing small projects. It's fun to work
with since it's got no defined structure, and will just save whatever you give
it wherever you say to.

That flexibility comes back to haunt it in larger projects. A typo in a query
can trigger a reindex of a huge collection, make moot GBs of index data, or
invalidate other queries that work on the same collection. It also demands
that the devs do lots of documentation on the data structures as you can't ask
mongo to tell you it's schema, it's just a collection of documents.

And if you work with a loosely typed language, be sure to type your inserts as
mongo is not a loosely typed datastore (coughPHPcough).

But for internal tools, and smaller projects, the speed of development is
great.

~~~
bricestacey
Some ODMs like Mongoid have a strict mode that requires a field to be mapped
in order to save it to the db. This saves you from typos wrecking havoc. You
should probably unit test your queries anyway.

~~~
FuzzyDunlop
Yeah. Mongoose on Node requires you to code and instantiate a document schema
before you can do anything with the database.

Gotta sacrifice some flexibility for a bit of safety.

------
foobarbazetc
I have no idea how anyone who's ever read the mongodb source code can entrust
it with their data.

~~~
eloop
Examples?

------
Deutscher
A few months ago, I saw an online interactive 'trainer' of sorts for MongoDB,
much like Codecademy's JS tutorials. Does anyone know what I'm talking about?

EDIT: Damn Google, you good: <http://www.mongly.com/>

~~~
mathias_10gen
It was probably either <http://try.mongodb.org> or <http://mongly.com/>

------
deleo
A bump like that should be for backward incompatible changes but it actually
looks like a makeover to appeal more to serious biz customers that would have
trouble getting on to a 1.0 technology.

------
nirvana
I'm curious as to why MongoDB is so popular. I chose Riak, and my purpose here
isn't to bash Mongo, but to understand what was the key feature that made you
choose it?

Is it pure speed on a single machine? Is it the query interface? Something
else? Datacenter awareness? Geographic support?

The key features that made me choose riak: \- built in distribution/clustering
with homogenous nodes \- bitcask had the level of reliability/design that I
was looking for. \- better impedance match for what I was doing than CouchDB
(which was what I looked at before choosing riak, but couch does view
generation when data is added and I need to be able to do it more
dynamically.)

What sold you on Mongo? What would you most like to improve?

(Please don't let this be a debate, I'm more interested in understanding the
NoSQL market, what other developers priorities are, etc.)

~~~
whyme
I struggle choosing. I started both at the same time and keep going back and
forth.

Riak

    
    
      -> I love the fault tolerance
      -> easier to scale with a dreamworld of hash-rings I wish I could have.
      -> no indexes
      -> no Geo-spatial indexes
      -> I don't like link walking... it's not intuitive.
      -> I want to use Riak (Lucerne/Solr like) full text search, but the docs are poor and have to read dozens of useless documents to get nowhere very quickly. It's a separate install that requires pre-commits?(which are never explained well enough to start using it).
      -> installing on Mac OSX is painful (homebrew works/doesn't work depending on version, 32 bit or 64? how come I don't have include 32bit flags with older repo's, yet newer ones are only 64bit yet don't compile.... errors errors errors...ERLANG which? such a pain in the ass installing Riak unless you do it using specific build tools.
      -> Only Joyent provides a hosted solution which is too expensive relative to its offering.
      -> accepts any docs just set the content type.. handles original documents without conversions
      -> easy to load balance behind NGINX
      -> can choose between conflicting writes 
    

MongoDB

    
    
      -> straight forward install.. up and running in no time
      -> SQL like queries
      -> intuitive indexes
      -> Geo-spatial indexes
      -> Affordable hosted services with more than one provider.
      -> no full text searching over documents
      -> have to fiddle with doc handling GRIDFS etc..
      -> can't choose between conflicting writes  (last one wins)
    

I wish I could have "RiaMong"

    
    
      -> straight forward install.. up and running in no time
      -> fault tolerance
      -> easier to scale with a dreamworld of hash-rings.
      -> indexes
      -> Geo-spatial indexes
      -> Affordable hosted services at with more than one provider.
      -> full text searching for documents
      -> handle original documents without conversions
      -> can choose between conflicting writes 
    

Oh well maybe someday :)

~~~
rzezeski
I work at Basho. Specifically I've been doing a lot of work on Riak Search
lately. I absolutely agree that the Search documentation is underwhelming and
could use some major love. I take it as a personal challenge to improve the
situation before the 1.0 release comes out.

That aside, you might like to know that for the 1.0 release Search is bundled
along with the standard Riak package (you just need to set a flag to enable
it). You can try using the latest pre-release or even build from source on
master or the 1.0 branch. If you don't actually need full-text search then you
could also checkout Riak's new support for secondary indexes. Please drop a
line on the mailing list or IRC if you have questions.

