Error Detection For Agile Schema-Evolution With Object Mappers In NoSQL Databases


Almost a year ago, I finished my bachelor's study at the Applied University of Regensburg. During my bachelor thesis, I've developed a software called EDASOMIND which is an abbreviation of Error Detection For Agile Schema-Evolution With Object Mappers In NoSQL Databases. NoSQL, especially if it is schemaless, is a powerful alternative to traditional relational database management systems. In his book "NoSQL distilled" Martin Fowler made the most important conclusion: Use the tools whichever fit to your use case. 


EDASOMIND is written in Java and available on a public repository on Github. The link provides you also with some setup instruction and the project itself contains examples which are used for testing.


By using NoSQL databases, the dbms most will not have the control of the schema anymore. That means, the developer has to care. This eases the fast, iterative and rapid deployment (especially web apps), especially if mechanisms like lazy migration are embedded. However, EDASOMIND assumes one has developed a software with MongoDB together with Morphia (An ORM for Morphia). With morphia, you can use POJO (Plain old java objects) and simply put them into your database without a lot of hassle. Additionally, morphia provides annotations (e.g. @Property or @AlsoLoad) to use in that pojos. As the software matures, a pojo will have a number of different versions each with different columns. This can create circuumstances in which the system will not work without problems. 

EDASOMIND's goal is to find those problems and warn the developer. This is done by extracting all previous versions of a pojo from a version control system (In this case Git), determine differences and conclude potential problems.

  1. A data class has been evolved, now it should be shipped to a server
  2. GitAccess takes the evolved data class and looks for previous versions in a git repository
  3. The retrieved source files are input for the JavaSourceParser (Which itself uses the Abstract Syntax Tree) to statically (Without compilation!) extract the member variables and their annotations
  4. The SchemaValidator uses the information, compares the results and concludes potential errors
  5. As a gimmick, potential errors were classified according to a traffic light. 

Module Structure

Leave a Comment

comments powered by Disqus