Data Lifecycle Management: Versions

Published in

Mendix Community

5 min readAug 24, 2021

The version of the cat

No one knows, but the creation of this drawing most probably a project. Maybe they designed the cat, the cat was created somewhere on a hill, the manager was not satisfied because it was too small, and they redrew it on this hill with some changes. As soon as the second cat was ready, the first cat was canceled and the hill was returned to how it was.

Apparently there are/were two versions of the cat, each version was initiated and activated. One of the versions even was canceled and later removed. We see that there are two versions: each with their own hill, their own size and their own status.

It’s not hard to see the similarity with administrative systems. In most systems some of the entities have a status. From a data management perspective, it is wise to allocate a version to ALL main entities (main entities are entities that have a representation in real life — you can actually see it — and are not for historical or association purposes.

In many cases users do not see the necessity for versions on objects: it simply was never a problem. But, if you don’t use them, there is no way to save information with them (the old hill), there is no way to find out why there was a new version (the cat was too small) and there is no way to reproduce exactly what happened. That’s the reason why, for main entities at least, you should always use versioning.

Version design

From a business perspective an entity with a status (so…: all main entities) looks something like this:

In general, almost all attributes and associations are stored in the entity version (e.g.an entity named ‘contract_version’). Only one of these versions can have the status ‘Active’ at any specific moment in time. If the entity is addressed directly, the active version contains all valid data on the entity.

The protocols for starting, ending and creating a new version may be different per company. However, the advice is to use the same protocols for all entities. E.g. If a new contract_version needs up-front approval to get active, why should a new product_version not need approval? The advantage of this approach is that it is easy, in the future, to decide that for some new products approval of new product_versions is mandatory because the versions and statuses already exist. For the other products the approval may be automated (status ‘waiting for approval’ is assigned for a short period of time only).

If you do it right once, it is not difficult to do it right the next time (replication).

Why would the business care?

Basically, using versions and statuses take care of the users’ data lifecycle:

· The lifecycle of an object is clear by inspecting its timeline, with all the versions on it.

· The activities needed to start an object, to change an object and too inactivate an object can be linked to the appropriate version (and status).

· Proper history.

As stated before flexibility is increased by having versioning established for all main entities.

Using a generic versioning feature

It makes sense then, before starting to build the app, to create this generic feature for versions, and use it for all (functional) entities that need versioning.

Using a generic status feature has advantages:

· It only needs to be developed and tested once. If it works, it can easily be added to another entity: it therefore increases the flexibility of the application.

· Functionality like version-history, timelines, protocols and data structures are developed just once and have guaranteed quality.

· Most important: a complete lifecycle of the entity is created, therefore (functional) trouble shooting, error-correction, audit-ability etc. are improved.

· Restoring a previous version of an object is easily done by de-activating the later versions.

The generic feature should:

· Handle creation of new versions.

· Handle version attributes and associations.

· Carry out checks that have to be made before a new version is created and validated.

· Applies protocols in order to perform changes to the entity.

· Applies protocols to undo changes applied to the entity and/or undo new versions.

· Takes care of the entity timeline.

· Keeps track of object statuses in the history.

How to apply versioning to an entity?

· Rename the entity from ‘entity’ too ‘entity_version’ with a new attribute ‘versionNumber’ (set to ‘1’).

· Create a new entity with name ‘entity’ and have a 1:n association with ‘entity_version’, add the identifying attributes to this new entity.

· For every ‘entity_version’ create and fill the ‘entity’ object, and create the association between them.

· That’s all. Now start developing the creation, conditions, and protocols for processing new versions of this entity.

I think that the entity itself should not contain a status. Its status is the result of the statuses of all its versions, so it’s a dynamic status.

- If there is only one entity_version with status ‘to be approved’, the dynamic status of the entity might be ‘upcoming’.

- If there is at least one entity_version with status ‘active’, the dynamic status of the entity might be ‘running’.

- If there are no ‘active’ entity_versions and the current entity_version is ‘inactive’, the dynamic status of the entity might be ‘suspended’.

- If there are no ‘active’ entity_version and the last entity_version has status ‘ended’, the dynamic status of the entity might be ‘ended’.

Mendix implementation

The functionality for versioning can easily be created in Mendix applications.

For each entity create microflows to:

· create new versions;

· check and approve creation of new versions;

· undo new versions.

In my opinion every application needs statuses on at least one entity (assuming it is necessary to at least administer something that is more-or-less reproducible). I would love it if this is included in a future version of the Mendix Platform, hopefully we will see this someday.

Although it is not a technical issue, it certainly is part of the functional data foundation of every administrative application.

If you want to know more about how to handle this functional feature, or copy mine, please get in touch.

Data Lifecycle management: Statuses

In my previous post, I examined an ancient drawing of a cat on a mountain. No one knows why it was made, but we know…

medium.com