The power of the InMemory plugin: Data retention Part 2

In this article was described the InMemory plugin.

Another important feature, the  auto configuration, will be described in depth.

Every developer which has managed data knows they are not completely defined during the design phase, but in the development cycles new information is managed.

If software is well designed adding new data will be simple. But if the design phase was poor, managing new data can lead to the redesign of the software, or, in the worst case, can start a patch driven development.

In the article was described that InMemory plugin uses an external database to store information for data retention, but any database engine needs a design phase to describe the tables, index, primary key, and so on.

With InMemory plugin, a developer needs to design the tables only on the database side. InMemory plugin, during start-up, prepares the InMemory tables reflecting the database tables: this approach reduces every possible error in the double definition of the information about the table in two different contexts: configure an InMemory plugin needs only information about the database instance and the tables to use. Then everything else is automatic.

There are other opportunities even after table definition has ended. If the developer needs to add new data it can redesign the database, fill in the missing data in the DB tables and restart the InMemory plugin (Hot Update feature): now, Sinapse System will use the new table structure, with the latest information stored.