Dec 9, 2015

MongoDB 3.2: Now Powered by PostgreSQL ?

Having said that MongoDB is listening to developers/ecosystem some months ago, today I have read an article MongoDB 3.2: Now Powered by PostgreSQL by @jdegoes that contradicts my own experience.
I will not categorize this article as one more mongophobic article that makes headlines from time to time here and there  like: 
Although I understand writer has some personal interest as he has invested in mongoDB Analytics, I have to admit that he is making a case that technically looks very sound to me "flattening out the data and using a different database to execute the SQL" is not the way to go for MongoDB BI solutions.
I also agree with much of his arguments when he tries to describe of what is going wrong with mongoDB's ecosystem.

Still I am not as pessimistic as the writer and I hope that:
  • a) This connector to BI tools is only a temporary quick fix solution and there are better tools coming in the pipeline.
  • b) MongoDB will listen to his arguments and comes with a revised policy regarding its partners and the ecosystem at large.
    The story of how $lookup ended up been part of community edition makes me believe that mongoDB can do that.

Sep 1, 2015

MongoDB is listening to developers/ecosystem

Today MongoDB 3.1.7 is released and shell includes the new CRUD API.
I am happy for this feature to be implemented and get into production so fast and feel really glad that I am the one who has triggered the introduction of this new API.
It all started 5 months ago when PyMongo 3.0 was introduced and A. Jesse Jiryu Davis the coauthor of pymongo wrote about new CRUD API in his blog where I posted a comment complaining that this is a step backword unless it is implemented in the shell API as well.
Jesse engulfed the idea opened a ticket at mongoDB's Jira then things started rolling. Today I was reading again his blog and was excited to realise suggestion was in production. I am also thankful to Jesse for his kind words and attribution and feel obliged to repeat those here:
The official announcement focuses on bug fixes, but I'm much more excited about a new feature: the mongo shell includes the new CRUD API! In addition to the old insert, update, and remove, the shell now supports insertMany, replaceOne, and a variety of other new methods. Why do I care about this, and why should you? MongoDB's next-generation drivers, released this spring, include the new API for CRUD operations, but the shell did not initially follow suit. My reader Nick Milon commented that this is a step in the wrong direction: drivers are now less consistent with the shell. He pointed out, "developers switch more often between a driver and shell than drivers in different programming languages." So I proposed the feature, Christian Kvalheim coded it, and Kay Kim is updating the user's manual. It's satisfying when a stranger's suggestion is so obviously right that we hurry to implement it.
I'm so glad we took the time to implement the new CRUD API in the shell. It was a big effort building, testing, and documenting it—the diff for the initial patch alone is frightening—but it's well worth it to give the next generation of developers a consistent experience when they first learn MongoDB. Thanks again to Nick Milon for giving us the nudge.
In an other occasion I requested a feature this time from pymongo's team a few days ago, that was a trivial one and easy to implement that was to name the threads that pymongo is creating for debugging purposes, of course I could have done it myself and request a pull from github but it involved naming conventions for which I was not sure, so I prefered to post a feature request in jira, Bernie Hackett responded "it seems a good idea" and to my suprise I saw this implemented in next release few days later.
What this story tells us developers is that we can request for features/fixes and can expect to see those implemented in reasonable time even if it is a major effort provided that:
  • our requests are reasonable and technically sound.
  • we document those properly.
  • we use proper channels to communicate.
  • the company/organization has a culture/history of listening to developers/ecosystem and those 2 examples proove that mongoDB is one of those.