This iteration we were mostly wrapping up the QA of Ops Manager 1.6 - Ops Manager 1.6 will include automation, a Windows build (backup and monitoring only), as well as an Automation API and will be releasing alongside MongoDB 3.0.
Customers will be happy to know that 2 Factor Authentication is now optional for users - you can try out the MongoDB Management Service for free without sharing your phone number with us.
Also added in this release were tons of new automation features:
- AWS cross-account access during server provisioning instead of using API Keys
- Provisioning of EBS Encrypted Volumes and EPS optimized instances
- We also now support the c4 instance types, allow provisioning across 24 SSDs available in the HS1 instance type, and we will validate the security group rules when publishing the deployment. Lastly, when the Automation Agent gzips log files we will now preserve the original timestamp.
There were also updates to the monitoring and backup agents:
- Monitoring agent (version 18.104.22.168) will stagger the timing of DNS look-ups, to avoid triggering a rare issue in glibc 2.19 on Ubuntu 14.04.
- Backup agent (version 22.214.171.124) has logging improvements for Windows
Thanks for reading!
Introducing the Legacy C++ Driver 1.0
The C/C++ Driver team at MongoDB is pleased to announce the 1.0 release of the legacy C++ driver. The legacy C++ driver provides a (mostly) compatible interface to previous releases of the C++ driver with many bugfixes, additional features, and a simplified implementation. In this post we will explain the reasons for creating the legacy C++ driver, the major improvements it offers, and our roadmap for the project going forward. The Road to the Legacy Driver For much of MongoDB’s history, the C++ driver was developed within the server repository . The server contains an internal client library used by the mongo shell and the mongos query router. The C++ driver was initially a separate build target that exposed this internal library to developers of standalone C++ applications that connected to MongoDB. However, using the server codebase as the basis of the driver had several consequences that negatively affected developer experience. For one, building and installing the C++ driver required the full server source code, making it unnecessarily difficult for C++ developers to get up and running. Much of the driver was shaped by implementation details of mongod and mongos, making it bloated and difficult to learn. Additionally, the driver lacked important features such as support for bulk writes. Overall, the usability, design and feature set of the C++ driver significantly lagged the drivers for other popular languages like Python, Java, and Ruby. Maintaining the driver as a component of the server codebase also put the needs of the server in conflict with that of the driver. Sometimes the server required changes to the codebase that were undesirable for users of the driver, and at other times there were changes desired by driver users that were unsuitable for the server. In other words, it was the was the worst of both worlds. As numerous StackOverflow and mongodb-user posts from unhappy developers indicated, connecting an application to MongoDB with the C++ driver was not a positive experience. By the MongoDB 2.6 release, it was finally decided that this state of affairs was untenable. The Fork In April 2014, with a mixture of SCons, git, and shell incantations, the minimal set of source files needed to build the driver was forked from the 2.6 codebase into a separate project . As detailed in an earlier post , we decided to maintain three branches of the C++ driver from that point forward: 26compat - a largely unchanged version of the driver with some changes backported from the server legacy - a mostly backwards compatible version of the driver to be actively developed and improved master - An entirely new and modern MongoDB driver written in C++11 Since the initial fork, there has been a frenzy of activity on the legacy branch of the C++ driver. To give a high-level overview: 320 JIRA issues resolved as “Fixed” 474 commits 402 files changed, 29,635 insertions, 19,003 deletions 14 contributors, 6 with more than 5 commits What are the major improvements? The surface area of the driver has been greatly reduced, with fewer client headers and functions published as part of the API, and a great deal of unnecessary functionality has been removed. The build system has been reworked as well, with idiosyncratic targets like ‘smokeCppUnitTests’ replaced with more obvious ones like ‘unit’. We’ve also added support for MongoDB 3.0 features. While there were breaking changes to the API, we believe that consumers of the 2.6 driver should have a fairly easy time migrating to the legacy 1.0 driver. Here is a list of some of the major improvements made to the legacy driver: Acknowledged writes are now the default Support for all write concern types Full support for write commands and bulk writes New helpers for using the MongoDB Aggregation Pipeline Support for SCRAM-SHA-1, the new default authentication mechanism in MongoDB 3.0 Support for big endian architectures (tested on SPARC) The driver’s test-suite now uses mongo-orchestration to run tests against multiple versions of MongoDB standalones, replica sets, and sharded clusters New helpers for writing Geospatial queries Greatly simplified build process Improved support for building the driver as a shared library What’s next for the legacy driver? Now that the legacy driver has stabilized, we will limit future changes to bug fixes and backports of relevant server commits. In addition, the driver will be updated as needed to support communication with MongoDB 3.2. What about the C++11 driver? Future development efforts will be focused on the master branch of the driver, which will feature a completely new API based on C++11 and other modern C++ design principles. A forthcoming blog post will provide an in-depth description of the new driver’s design and features. We want your feedback! We also would like to hear feedback from the community on the legacy driver - please reach out to the developers on the mongodb-user list with any questions, or file tickets for any bugs on the JIRA tracker in the CXX project . We also welcome pull requests submitted on the driver’s GitHub page . If you’re interested in learning more about the architecture of MongoDB, download our guide: Download the Architecture Guide About Adam Midvidy Adam Midvidy is an engineer on the MongoDB Platforms Team and a contributor to the Legacy C++ Driver.
Introducing MongoDB Realm’s Flexible Sync – Now Available in Preview
Twelve months ago, we made MongoDB’s edge-to-cloud data synchronization service, Realm Sync , generally available. Since then, Sync has helped hundreds of our customers build reliable, offline-first mobile apps that serve data to millions of end users – from leading telematics providers to chart-topping consumer apps . Historically, Realm Sync has worked well for apps where data is compartmentalized and permissions rarely change, but dynamic use cases with evolving permissions required workarounds. We knew we could do more, so today we are excited to announce the next iteration of Realm Sync – Flexible Sync. With the introduction of Flexible Sync, we are redefining the sync experience by enabling even the most complex use cases out-of-the-box without requiring any custom code. Intuitive query-based sync Distinctly different from how Realm Sync operates today, Flexible Sync lets you use language-native queries to define the data synced to user applications. This more closely mirrors how you are used to building applications today – using GET requests with query parameters – making it easy to learn and fast to build to MVP. Flexible Sync also supports dynamic, overlapping queries based on user inputs. Picture a retail app that allows users to search available inventory. As users define inputs – show all jeans that are size 8 and less than $40 – the query parameters can be combined with logical ANDs and ORs to produce increasingly complex queries, and narrow down the search result even further. In the same application, employees can quickly limit inventory results to only their store’s stock, pulling from the same set of documents as the customer, without worrying about overlap. Document-level permissions Whether it’s a company’s internal application or an app on the App Store, permissions are required in almost every application. That’s why we are excited by how seamless Flexible Sync makes applying a document-level permission model when syncing data – meaning synced documents can be limited based on a user’s role. Consider how an emergency room team would use their hospital’s application. A resident should only be able to access her patients’ charts while her fellow needs to be able to see the entire care team’s charts. In Flexible Sync, a user’s role will be combined with the client-side query to determine the appropriate result set. For example, when the resident above filters to view all patient charts the permission system will automatically limit the results to only her patients. Real-time collaboration optimizations Flexible Sync also enhances query performance and optimizes for real-time collaboration by treating a single object or document as the smallest entity for synchronization. This means synced data is shared between client devices more efficiently and conflict resolution incorporates changes faster and with less data transfer than before. Getting started Flexible Sync is available now. Simply sign up or log in to your cloud account, deploy a free Realm app, select your sync type, and dive right in. Have questions? Check out our documentation or the more detailed announcement post on the Developer Hub. Looking ahead Our goal with Flexible Sync is to deliver a sync service that can fit any use case or schema design pattern imaginable without custom code or workarounds. And while we are excited that Flexible Sync is now in preview, we’re nowhere near done. The Realm Sync team is planning to bring you more query operators, permissions integrations, and enhancements over the course of 2022. We look to you, our users, to help us drive the roadmap. Submit your ideas and feature requests to our feedback portal and ask questions in our Community forums . Happy building!