Lisk Research – Quick Overview of LIP 11

by francescov · Published August 24, 2019 · Updated August 26, 2019

Here we are with a new article to discover another LIP regarding the Lisk Research. This time we will deal with LIP 11, which suggests the use of an Extended Data Mapper pattern for the database component described in the LIP 5.

The author of the LIP 11 is Nazar Hussain, with the support of Oliver Beddows and Andreas Kendziorra. They propose a universal, easily understandable and structured model that will serve to expand and preserve the persistence layer of Lisk Core.

Developers explained that, in the current Lisk Core model, the logic in charge of the data persistence is irregularly disseminated among different parts of codes. The result of such a distribution is the presence of superfluous interfaces for equivalent functionalities, which increases the difficulty in maintaining and extending the code over time. In addition, there is no uniform design between all these interfaces, making it difficult to determine which one should be used by which modules.

The logic distribution in the current Lisk Core implementation is shown in the above diagram: it is possible to notice the mentioned difficulties in choosing the proper interface, due to their duplication. The picture also shows, for example, that there are several interfaces available to get accounts from the database. Moreover, the interfaces are currently strongly linked with the database solution used by Lisk Core – PostgreSQL RDBMS.

LIP 5 (which we discussed in this article) implies the sharing of interfaces among all modules, with the purpose of getting data from the persistence layer. This moves to a complicated situation where it is difficult to determine which namespace should be shared among modules. The model proposed by developers faces this problem by means of a definite abstract layer for the persistence logic, satisfying the requirements of LIP 5.

The new design pattern must be characterized as follows:

Maps of the code entities through the system to database equivalents;
Provides an easy way to widen an entity in order to create a new specialized entity;
Supports mapping entity attributes across multiple database tables;
Secures the data access layer by allowing restricted access permissions to interfaces and exposed read-only instances for external modules;
Isolates the implementation of entities, in order that other modules should not have access to module specific entities.

Developers suggest three possible design patterns used in the software industry that could satisfy the aforementioned needs:

Active Record: suitable for medium size projects but not in the case of Lisk, which has millions of data objects. Furthermore, this pattern does not meet the requirement of mapping entity attributes across multiple database tables, so it cannot be implemented;
Data Mapper: it is based on native JSON objects for higher performance and it has bi-directional serialization support from JSON to a database. It also supports mapping entity attributes across multiple database tables but it restricts to have only CRUD interfaces on every entity;
Repository: its flexibility makes it possible to implement it in various ways. However, having no standards or guidelines, it cannot be used to implement consistency across interfaces and behaviours.

In conclusion, the solution proposed by the developers consists in the union of the data mapper pattern with the repository pattern, in order to support both standard CRUD operations and flexible interfaces. The new pattern has been named “Extended Data Mapper” and below you can see the diagram that describes its architecture.