Skip to content

Module versioning

damiencorpataux edited this page Jul 8, 2013 · 17 revisions

Module Versioning

Le versioning permet de stocker les différences à chaque modification d'un enregistrement en base de données. Il a les caractéristiques suivantes:

  • En lecture seule par nature
  • Table de stockage à clé primaire BIGINT pour supporter un grand nombre d'enregistrements
  • Implémente la gestion d'accès, l'utilisateur ne peut accéder qu'à l'historique des ressources auxquelles il a accès
  • Une version correspond à une et une seule opération CRUD sur un tuple

Par défaut, chaque action de modification d'une table en base de données (read, update ou delete) donne lieu à la création d'une version.

La création d'une version est réalisée par le stockage des différences lors de la modification d'un tuple. Ces différences sont stockées sous forme de clé-valeur consignant la valeur d'avant et d'après la modification pour chaque champs modifié du tuple en question.

Le versioning stocke une liste des tuples concernés pour chaque version, dans la table versions_relations. La liste des tuples concernés désigne l'ensemble des tuples d'autres tables référencés par le tuple en cours de versionnage - et ceci de manière récursive. Par exemple, la modification d'une adresse impacte personne_adresse, personne et commission si la personne est dans la commission.

Chaque différence étant stockée sous forme de version, n'importe quelle version d'un tuple peut être reconstituée - en prenant la version courante d'un tuple et en y appliquant successivement et dans l'ordre déchronologique les différences de chaque version.

Implémentation

Le versionning est implementé dans la classe iaModelMysql.

Stockage des données

Le stockage des versions est effectué dans les tables versions, versions_data, et versions_relations.

La table version contient un tuple pour chaque version

  • information sur le modèle relatif
  • identifiant de version et date de création
  • operation ayant donnée lieu à la version (put, post, delete, tag)

La table version_data contient les données de version à proprement parler, un tuple par champs modifié:

  • id version
  • nom du champs modifié
  • ancienne valeur et nouvelle valeur du champs

La table versions_relations contient référence les tuples impacté par la version, un tuple par tuple impacté:

  • id version
  • nom de modèle et de table
  • nom du champs de clé primaire
  • id du champs clé primaire

Signification des types de versions

Chaque version est associée à une opération:

  • put: ajout d'un tuple
  • post: modification d'un tuple
  • delete: suppression d'un tuple
  • tag: aucune modification de données, mais stockage d'un jalon associé à un libellé

Processus de versioning

Lors de la création d'une version, les opérations suivantes sont effectuées:

  • Création du tuple dans la table versions
  • Création des tuples contenant les valeurs modifiées dans la table versions_data
    Un tuple par champs modifié
    Les valeurs anciennes et nouvelles sont stockées
  • Création des tuples référençant les tuples implactés dans la table versions_relations Les tuples référençant le tuple modifié sont stockés

Dans le cas de la création d'un tag, aucun information n'est stockée dans la table versions_data.

Récupération des données

Un modèle versionné doit obligatoirement comporter un champs actif de type booléen. Ce champs indique si l'enregistrement est supprimé (actif=false) ou non. De ce fait, les tuples d'un modèle versionné ne sont jamais supprimés de la base de données.

Il est possible de récupérer une version voulue à partir des informations suivantes:

  • le tuple tel qu'il existe en base de données (version actuelle)
  • les données de versions jusqu'à la version voulue

Le processus est le suivant:

  • Récupération de l'enregistrement tel qu'il existe en base de données
  • Application de toutes les modifications jusqu'à la version voulu

Dans le cas d'un enregistrement supprimé:

  • Le champs actif passe à false et l'enregistrement est considéré comme supprimé