5 ms·

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 thei

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.

davidw 14y ago
Pretty much anything can be made to work for small projects. Even stodgy old SQL projects like Postgres which pay a lot of attention to being correct and doing their damndest to preserve your data.
- smoyer 14y ago
  Gasp ... I'm just about to use "stodgy old PostgreSQL" in a new project. I guess I'm old enough now that perhaps I'm stodgy myself.
  - lotyrin 14y ago
    I don't think so. I fell in love with PostgreSQL in High School and that love only continues into my 20s.
  - deleted 14y ago
    [deleted]
  - taligent 14y ago
    It's a shame that PostgreSQL hasn't come into the 21st century with decent clustering and replication support. The big trend of the last couple of years has been moving from scaling vertically to horizontally. PostgreSQL's inability to keep up with this has been disappointing and a missed opportunity.
ukd1 14y ago
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 14y ago
  > 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 14y ago
    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.
    - jamesaguilar 14y ago
      If people are relying on the current speed, changing the default to safe would break them.
    - mathias_10gen 14y ago
      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.py#L51-57 https://github.com/RedBeard0531/Mongurl/blob/master/mongurl.... That said, it makes sense for this to be opt-in behavior rather than the default.
- MichaelGG 14y ago
  If it's properly deprecated, the old constructor should cause a compiler warning with a message explaining the issue. This way, old and new users of the new library will get the message, even if the sample uses the old constructor. At least in languages that support that feature (.NET, Java, C++ with some extensions). A more aggressive approach, used e.g. in the CLR for really serious problems (like the improper HMAC calculation bug, or background threads not aborting in CLR < 2.0) give you a warning and allow you to switch it off via config, so no code change is required, but everyone gets the "fix".
rdtsc 14y ago
Yes everyone here hates mongo because that is cool and they are all irrational, not because up until, well ... now, it had been calling itself a 'database' product while specifically defaulting to doing the least possible to make sure your data actually hits the disk. But hey, it looks good in benchmarks, and it is WebScale(tm) and anyone who hates that kind of thing is just an irrational hater.
- taligent 14y ago
  Well actually the default is set by the drivers not the database. And many of the third parties have set the defaults to the safer setting for years now. But hey don't let that get in the way of your irrational ranting.
- darkarmani 14y ago
  > it had been calling itself a 'database' product while specifically defaulting to doing the least possible to make sure your data actually hits the disk Being a database doesn't mean you have to persist on disk. There is nothing wrong with in-memory databases. If you thought they were giving you persistence guarantees, then yeah, you would have a gripe.
  - z92 14y ago
    In memory databases are explicitly marketed as "in-memory database". Not simply as "database" because that delivers some expectations to people. And those expectations are generally not verified with the dictionary definition of database.
willholloway 14y ago
Mongo made it extremely easy for me to create local caches of JSON api data. I didn't want to go through the hassle of mapping postgres schema or dealing with it's hstore data type. I was then able to write a quick script to copy my mongo database over to elasticsearch. It was a joy.

davidw 14y ago

Pretty much anything can be made to work for small projects. Even stodgy old SQL projects like Postgres which pay a lot of attention to being correct and doing their damndest to preserve your data.

smoyer 14y ago
Gasp ... I'm just about to use "stodgy old PostgreSQL" in a new project. I guess I'm old enough now that perhaps I'm stodgy myself.
- lotyrin 14y ago
  I don't think so. I fell in love with PostgreSQL in High School and that love only continues into my 20s.
- deleted 14y ago
  [deleted]
- taligent 14y ago
  It's a shame that PostgreSQL hasn't come into the 21st century with decent clustering and replication support. The big trend of the last couple of years has been moving from scaling vertically to horizontally. PostgreSQL's inability to keep up with this has been disappointing and a missed opportunity.

ukd1 14y ago

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 14y ago
> 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 14y ago
  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.
  - jamesaguilar 14y ago
    If people are relying on the current speed, changing the default to safe would break them.
  - mathias_10gen 14y ago
    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.py#L51-57 https://github.com/RedBeard0531/Mongurl/blob/master/mongurl.... That said, it makes sense for this to be opt-in behavior rather than the default.
MichaelGG 14y ago
If it's properly deprecated, the old constructor should cause a compiler warning with a message explaining the issue. This way, old and new users of the new library will get the message, even if the sample uses the old constructor. At least in languages that support that feature (.NET, Java, C++ with some extensions). A more aggressive approach, used e.g. in the CLR for really serious problems (like the improper HMAC calculation bug, or background threads not aborting in CLR < 2.0) give you a warning and allow you to switch it off via config, so no code change is required, but everyone gets the "fix".

rdtsc 14y ago

Yes everyone here hates mongo because that is cool and they are all irrational, not because up until, well ... now, it had been calling itself a 'database' product while specifically defaulting to doing the least possible to make sure your data actually hits the disk. But hey, it looks good in benchmarks, and it is WebScale(tm) and anyone who hates that kind of thing is just an irrational hater.

taligent 14y ago
Well actually the default is set by the drivers not the database. And many of the third parties have set the defaults to the safer setting for years now. But hey don't let that get in the way of your irrational ranting.
darkarmani 14y ago
> it had been calling itself a 'database' product while specifically defaulting to doing the least possible to make sure your data actually hits the disk Being a database doesn't mean you have to persist on disk. There is nothing wrong with in-memory databases. If you thought they were giving you persistence guarantees, then yeah, you would have a gripe.
- z92 14y ago
  In memory databases are explicitly marketed as "in-memory database". Not simply as "database" because that delivers some expectations to people. And those expectations are generally not verified with the dictionary definition of database.

willholloway 14y ago

Mongo made it extremely easy for me to create local caches of JSON api data. I didn't want to go through the hassle of mapping postgres schema or dealing with it's hstore data type. I was then able to write a quick script to copy my mongo database over to elasticsearch. It was a joy.