
MongoDB writes to be safe/verified by default - mrkurt
http://blog.mongodb.org/post/36666163412/introducing-mongoclient?yey
======
programminggeek
This seems like a very sane way of handling this particular issue. I know it's
cool to hate on MongoDB these days, but I've always liked the way they built
their product. Maybe at ridiculous scale it's not as awesome, but it's been
pretty decent for me on the small projects I used it on.

~~~
ukd1
I think this seems a pretty insane way of doing it; why not change the default
behavior instead of making another driver with a separate name as well as
keeping the old one too?

This is likely to be super confusing to new users; rumours that it's write
safe and all the common examples will be fore the old driver...

IMHO they should have altered the defaults; people who require the extra
performance will likely be the ones reading the changelogs / docs / these
posts and notice.

~~~
msbarnett
> I think this seems a pretty insane way of doing it; why not change the
> default behavior instead of making another driver with a separate name as
> well as keeping the old one too?

Because, as they clearly explain in their rationale, that would break
compatibility with all of the existing software out there that relies on the
current semantics.

Thou Shalt Not Break Working Code is the first rule of building software that
other software relies on.

They're deprecating but retaining the old driver to give people a transition
period in which to modify their software instead of kicking them in the teeth
immediately or forcing them to hold off on upgrading. That's the mature
approach to fixing mistakes that people nonetheless built assumptions around.

~~~
ukd1
What does it break? This new default makes it behave as most users of it would
have expected it too when writing their code. IMHO the users who require un-
safe writes will be the ones to read this kind of news and notice and could
alter it, if needed. I don't think this is true vice versa.

~~~
mathias_10gen
One case that could break by this change is if you relied on insert's old
default of being a no-op if an object with the same _id already exists. This
can be used to efficiently insert a default document without race conditions.
Example at
[https://github.com/RedBeard0531/Mongurl/blob/master/mongurl....](https://github.com/RedBeard0531/Mongurl/blob/master/mongurl.py#L51-57)

That said, it makes sense for this to be opt-in behavior rather than the
default.

------
six
Sadly it seems that the "ubuntu generation" of people who don't RTFM have won
out.

The sheer amount of recent MongoDB hate has been extremely annoying, not to
mention the half-assed reasons for justifying it - we've learned a lot of
things from running MongoDB at scale, and none of them are what the haters
usually whine about.

~~~
meghan
Glad that you are having success with MongoDB at scale. Have you considered
sharing your experiences? Would be really helpful for others to learn from
you.

~~~
biscarch
Seconded. I'd love to see a post about your experiences.

------
MichaelGG
Still seems like an awfully long time to switch to proper defaults -- 3 and a
half years?

~~~
wmf
They had to wait until their unsafe benchmarks had killed off the competition.

~~~
malkia
LOOOOL!

------
jeffdavis
A good decision. I know backwards compatibility is important, but safe
defaults are an important aspect of usability.

Also, it's difficult to change something after defending it for a while.
That's a promising sign.

------
ericcholis
I know that the case is for safe is obvious, and I'm happy about the switch.
However, read the manual before getting your CAT6 in a twist. I really want to
use Postgres for an upcoming project, so I plan to read everything I can about
it. A sane developer tests, reads, tests again, swears a lot, drinks coffee,
and reads again. Try to find every damn pitfall you can digest. You will spend
an exorbitant amount of time reading, but you'll be better for it.

------
ericflo
This is fantastic news!

------
dkhenry
So for any of us who have been responsible and actually used the fire and
forget behavior of the previous driver here is the API call that you can use
to revert back

[http://api.mongodb.org/java/2.6/com/mongodb/Mongo.html#setWr...](http://api.mongodb.org/java/2.6/com/mongodb/Mongo.html#setWriteConcern\(com.mongodb.WriteConcern\))

------
nviennot
That reminds me of <https://github.com/mongoid/moped/pull/92>

------
websauce
I switched to MongoDB because devnull is webscale. Why take the speed of
devnull away from new users?

------
rogerbinns
I think the single biggest mistake they made was calling the option "safe".
That is obviously ludicrous! They should have called it exactly what it is -
"async".

~~~
fruchtose
Don't you mean safe mode is the synchronous version? The original default was
asynchronous error checking.

~~~
rogerbinns
What I mean is that instead of calling it "safe" they should have called it
"async". "safe" is the wrong terminology to use.

~~~
pork
No. Both the "safe" and "unsafe" versions are asynchronous. The safe version
waits for a response from the server before invoking a callback. The unsafe
version does not, but that doesn't make it synchronous -- the operation is
still potentially executing on the server when the function returns.

~~~
rogerbinns
This completely misses the point! I am talking about what the API does which
is what you are using. Whether it internally makes one over the wire call or
10 is irrelevant. With the parameter set one way, the API does not return
until the server has completed the operation, and the other way the operation
could still be in progress or could have errored - you have to explicitly ask.

My contention is that "safe" is a bad name for the parameter, and "async" is
far better suited as it describes the semantics of the API.

