Persistence Layer

The data entry forms managed in the presentation layer commit and retrieve data through the macaw.api.MacawCurationAPI. This API is implemented as both an in-memory and an SQL database. The in memory database is a simple collection of classes that manage instances of classes defined in the package macaw.model. The class DemonstrationCurationService is a class which delegates many of the implementations of methods defined for MacawCurationAPI to various manager classes. These classes in turn manage the add, update, delete and get operations for key concepts. Each manager class is also responsible for validation routines which check that a given object exists or that it isn’t a duplicate.

Wherever possible, classes that appear in one kind of implementation have corresponding classes in the other implementation. Figure Arch-Persistence-1 shows an example of this:

Fig. Arch-Persistence-1: Parallel development of in-memory and SQL-based implementations of the MacawCurationAPI. Please note that in the documentation, the diagrams need to be updated so that MacawDemonstrationDatabase is DemonstrationCurationService and MacawProductionDatabase is ProductionCurationService.

Figure Arch-Persistence-2 shows an example of how the notion of a value label manager is implemented using both in-memory and SQL-based storage. Wherever possible, the two classes have exactly the same methods but the SQL-based manager class has the additional parameter of a database Connection object.

Fig. Arch-Persistence-2: Parallel in-memory and SQL implementations of a value label manager class.

The in-memory database is used to support Macaw’s demonstration mode in a way that requires neither the installation of a MySQL database nor the presence of sensitive data from the production database. The in-memory database simulates updates and changes by always returning cloned copies of master objects. For example, when a new Variable is created, the InMemoryVariableManager adds it to a list of variables. When the variable is requested, InMemoryVariableManager clones the original Variable record and returns that instance to the client. The cloning mechanism allows the DemonstrationCurationService to support the notions of original and modified versions of the same records. The implementation needs this to support Macaw’s ability to create an audit trail of changes made to records.

Macaw’s support for auditing changes depends on a couple of features in the code base. Each major class in the package macaw.model has a method detectFieldChanges, which compares two instances of that class. It compiles a list of changes and returns them to the caller. When curators edit records, the detected changes are managed by a Change Event Manager that is implemented in both production and demonstration implementations of the database.

Author: Kevin Garwood