Reprinted from mongodb.com:
When compared to relational databases, NoSQL databases are more scalable and provide superior performance, and their data model addresses several issues that the relational model is not designed to address:
- Large volumes of rapidly changing structured, semi-structured, and unstructured data
- Agile sprints, quick schema iteration, and frequent code pushes
- Object-oriented programming that is easy to use and flexible
- Geographically distributed scale-out architecture instead of expensive, monolithic architecture
In this post, I will show you how to integrate NoSQL databases into your OutSystems application. Plenty of flavors of NoSQL exist; Redis and CouchDB are two examples. For this demonstration, I chose MongoDB, a high-performing and well-recognized open-source NoSQL option.
Step 1: The Extension
Developers may deploy MongoDB databases as standalone web services using any number of REST libraries that provide full exposure to the underlying NoSQL database. Examples include Eve, RESTHeart, and Crest. For this exercise, I chose the C# Driver approach to demonstrate how to extend the OutSystems platform.
The OutSystems extension manager allows you to create C# code and expose its methods to the platform. For this MongoDB extension, I needed some form of connection, collection management, and document CRUD & find. In Microsoft Visual Studio, I just needed to grab the MongoDB libraries and build a wrapper around them.
I published the extension and referenced my dependencies. Now, I was ready to start.
Step 2: The Core
Typically in these situations, we want to create some sort of abstraction layer. This core module implements a set of public methods that allow our applications to manage the database, the collection, and the documents therein. I’ve also included a set of private methods, DocumentHelpers, which hides some of the complexity.
Step 3: My Demo Application
Using the module, we can define the database documents with standard OutSystems structures and data types. In this example, I’ve created a “Person” document with a handful of attributes, one of which, “Contacts,” is a list of contact structures. This one-to-one data mapping allows us to work with MongoDB entries as if they were standard database elements, which reduces the learning curve significantly.
Step 4: Data Load
Being an OutSystems demo, it wouldn't be complete without a proper data load. I used an Excel file with people and their respective contact information stored in a tabular format. To populate the initial database, I created a Boot_DB method, which parses the data into JSON and then creates an entry in my MongoDB Person collection.
Step 5: List Screen
The next step was to build a typical list screen with OutSystems. I started by creating a local variable (Person list) that I populate during preparation and refresh on pagination. To recover each “Person,” I created PersonList, a generic method that accepts details like filter, sort, starting list index, and so on to help narrow the results and improve the user experience.
Step 6: Edit Screen
For a typical edit screen, I needed another helper method that could locate a document by its identifier and serialize the output directly into an OutSystems structure. I also created respective delete and save methods. The save method (PersonCreateOrUpdate) pulls the document data from an OutSystems structure, serializes it into JSON, and sends it to MongoDB.
Step 7: Changing the Data Model
Changing the model is trivial thanks to the fact that NoSQL does not have a formal document structure. I added a date-time to the Person structure, and it did not break MongoDB. The database was perfectly happy to assign date-times to some documents, and nothing of the sort to the remainder. This leaves our applications responsible for updating and maintaining the document structure.
Step 8: Take It For a Spin
Have fun with NotOnlySQL.