eXo Platform utilise Liquibase pour gérer les évolutions de sa base de données. Cela permet de mettre à jour facilement le schéma de la base de données (ajouter/supprimer une table, ajouter/supprimer une colonne, ajouter un index, …) ou son contenu (mise à jour des entrées, …).
Ces changements sont définis comme une liste de changesets que Liquibase va appliquer quand il sera exécuté (au démarrage d’eXo Platform dans notre cas). Quand un changement est appliqué, Liquibase sauvegarde cet état dans ses données et le changement ne sera plus appliqué aux prochaines exécutions.
Liquibase vérifie également que le changeset n’a pas été modifié dans le fichier par rapport à la version qui a été appliquée. Et c’est de ce sujet dont nous allons parler ici.
Bien que ce soit une bonne pratique de ne pas modifier les changesets déjà appliqués, c’est parfois nécessaire. Nous allons voir dans quelles situations et comment le faire. Mais commençons par nous plonger un peu dans les mécanismes internes de Liquibase.
...
…
ID: 1.0.0-1
AUTHOR: wiki
FILENAME: db/changelog/wiki.db.changelog-1.0.0.xml
DATEEXECUTED: 2016-04-13 07:14:29
ORDEREXECUTED: 22
EXECTYPE: EXECUTED
MD5SUM: 7:4714e3fc16bfa2cac4dde34703a4f58f
DESCRIPTION: createTable
COMMENTS:
TAG: NULL
LIQUIBASE: 3.4.1
CONTEXTS: NULL
LABELS: NULL
Le champ MD5SUM contient le checksum du changeset. Chaque changement dans le changeset dans le fichier XML engendrera un checksum différent.
A chaque exécution, pour chaque changeset défini dans le fichier XML, Liquibase vérifie si son id/author (dans notre exemple : 1.0.0-1/wiki) est présent dans la base:
Cela permet d’être sûr qu’un changement n’est appliqué qu’une seule fois, et qu’un changeset déjà appliqué n’a pas été modifié.
Mais certains cas nécessitent la modification de ces changesets.
La raison principale pour laquelle il est nécessaire de modifier un changeset est lorsqu’il échoue à s’appliquer, quelque soit la raison, par exemple à cause d’un bug, ou parce qu’on veut supporter une nouvelle base de données ou une nouvelle version d’une base de données non compatible avec le changeset.
Prenons un exemple réel avec un bug eXo Platform : Data initialization issues at startup with MySQL 5.7.14+. A partir de MySQL 5.7.14, les changesets de eXo Social échouent à s’appliquer sur une base de données vide, à cause de l’erreur “Invalid default value for ‘CREATED_DATE’”, alors qu’ils s’appliquent correctement sur les précédentes versions de MySQL. Dans ce cas de figure, la seule solution est de modifier le changeset dans le fichier XML.
Une autre raison pour modifier un changeset est lorsque l’on veut optimiser les changesets. Après plusieurs versions de votre application, certaines opérations effectuées vont probablement être inutiles. Par exemple, un premier changeset crée une table, puis un autre change la valeur par défaut d’une des colonnes de cette table, et finalement un dernier changeset supprime cette colonne puisqu’elle n’est plus nécessaire pour l’application. Si vous deviez concevoir votre application maintenant, vous ne créeriez pas du tout cette colonne, mais à cause de Liquibase, quand votre application va démarrer sur une base de données vide, la colonne sera créée, modifiée et supprimée. Dans ce cas de figure, modifier le changeset initial pour supprimer la colonne est intéressant.
Un article intéressant est disponible sur ce sujet dans la documentation de Liquibase.
Supposons que nous sommes dans le cas où nous voulons modifier un changeset parce qu’il échoue à s’appliquer. Nous voulons :
Comme expliqué précédemment, si nous essayons de simplement modifier le changeset, le premier objectif sera atteint, mais pas le second. Liquibase va détecter ce changement (le checksum du changeset du fichier XML est différent de celui dans la base Liquibase) pour les instances déjà initialisées et va lever une erreur.
La solution est d’ajouter dans le fichier XML le nouveau checksum (celui du changeset après la modification) à l’aide de la balise validCheckSum.
Par conséquent, le processus pour modifier un changeset est :
2017-05-06 10:52:15,082 | ERROR | Error while applying liquibase changelogs db/changelog/wiki.db.changelog-1.0.0.xml - Cause : Validation Failed:
1 change sets check sum
db/changelog/wiki.db.changelog-1.0.0.xml::1.0.0-42::wiki is now: 7:21d239448c33f39a9300ea433349d470
7:21d239448c33f39a9300ea433349d470
… // content of the changeset (with the update)
Cela permet en fait de dire à Liquibase que le checksum 7:21d239448c33f39a9300ea433349d470 est également un checksum valide (en plus de celui présent dans la base Liquibase).
Votre serveur eXo Platform démarre maintenant correctement dans tous les cas (avec une base vide ou non) !
intranet is a term used with abundance whenever the subject of internal communication and collaboration is brought up which makes defining it a bit challenging. In its simplest form, an intranet is an internal website for your organization. It is used mainly for top-down communication where employees can access corporate news, policies and announcements.
To gather a thorough understanding of intranets and their different types, let’s walk through its history from the early days up to now:
The main difference between intranets and extranets lays in the target audience. Intranets typically target users from a specific organization whereas extranets is the hub that can group users from multiple external organizations ranging from partners and suppliers all the way to clients
➝ Discover the real difference between intranet and extranet
Different types of Intranet solutions from the early days up to the intranet 2.0 (commonly referred to as digital workplace solutions) bring a host of benefits to businesses of all sizes and industries. Below is a list of benefits often associated with intranets:
Here are three different strategies for a successful intranet adoption: