Schemaless Databases

Old data, new application

If we’re using something other than a relational database, then we’re done. A schemaless database is only schemaless as far as the database engine cares. Our application is another story entirely. It expects certain structure in the documents, values, or graph nodes returned by our database. Will all the old documents work on the new version of our application? We mean all the old documents, way back to the very first customer record we ever created. Chances are your application has evolved over time, and old versions of those documents might not even be readable now. Harder still, our database may have a patchwork of documents, all created using different application versions, with some that have been loaded, updated, and stored at different points in time. Some of those documents will have turned into time bombs.

Reading old documents on new app versions

If we try to read one today, our application will raise an exception and fail to load it. Whatever that document used to be, it effectively no longer exists. There are three ways to deal with this.

All-version compatible app

First, write our application so it can read any version ever created. With each new document version, add a new stage to the tail end of a translation pipeline like the one shown in the figure below. In this example, the top-level reader has detected a document written in version 2 of the document schema. It needs to be brought up-to-date, which is why the version 2 reader is configured to inject the document into the pipeline via the “version 2 to version 3 translator.” Each translator feeds into the next until the document is completely current. One wrinkle: If the document format has been split at some point in the past, then the pipeline must split as well, which is shown in the figure that follows.