Feat: Add a dbMigration service

Hello,

Cette PR fait suite au bug remonté sur Semapps https://github.com/assemblee-virtuelle/semapps/issues/1185.
La conclusion de la discussion étant qu'il était trop tôt d'intégrer un service de migrations dans Semapps, je me permets donc de proposer un service équivalent ici.

Contexte

Le service s'inspire des autres solutions de migration de base de données existants (tels que https://db-migrate.readthedocs.io/en/latest/, https://knexjs.org/guide/migrations.html#migration-cli or https://phinx.org/).

Le principe est qu'à chaque opération de migration nécessaire en base de données, on crée un fichier de migration, qui contient les opérations pour migrer (up), ainsi que les opérations pour revenir à l'état précédent (down). Chaque migration appliqué est sauvegardé en base de données pour savoir l'état actuel d'exécution des migrations.

Proposition

Un service dbMigrations créé ici reprend ce principe, en s'interfaçant avec Moleculer et le TriplestoreService.
Les fichiers de migrations sont stockés dans le répertoire middleware/migrations.
L'état des migrations est sauvegardé dans la base de données dans un nouveau graph nommé http://semapps.org/migrations. Un CLI nommé dbMigrate a été ajouté répliquant les actions du service dbMigrations mais pouvant être lancé en parallèle ou indépendamment du middleware.

Création d'une nouvelle migration

Pour créer une nouvelle migration, on peut utiliser la commande yarn run dbMigrate --name <nomDeLaMigration>. Celle-ci va créer un nouveau fichier js dans le dossier de migrations, préfixé par un timestamp pour pouvoir ordonner les migrations dans l'ordre chronologique.

Le contenu du fichier créé correspond à ceci :

module.exports = {
  up: async ({ query, insert, update }) => {
    /*
     * You can use 'query', 'insert' and 'update' actions from triplestore service
     * Documentation for these methods can be found here: https://semapps.org/docs/middleware/triplestore
     * Example:
     *
     * const queryResult = await query({
     *   query: `
     *     SELECT ?s ?p ?o
     *     WHERE {
     *       ?subject ?predicate ?object
     *     }
     *   `,
     * });
     */

  },
  down: async ({ query, insert, update }) => {
    /*
     * This function must undo what is done in the above "up" function.
     * If things are not undoable, it must ensure that the database will be in a coherent working state
     */

  },
};

Lister le statut des migrations

On peut lister le statut des migrations via la commande yarn run dbMigrate status. Celle-ci affiche un tableau avec le nom de chaque migration trouvée (dans les fichiers et/ou dans la base de données), leur statut (Not applied ou Applied) et leur éventuelle date d'exécution pour celles appliquées.

Appliquer une migration

On peut appliquer une migration via la commande yarn run dbMigrate up.

Sans aucun argument, la prochaine migration non-appliquée sera appliquée.
Avec un argument --name <NomDeLaMigration>, seule cette migration sera appliquée
Avec l'argument --latest, toutes les migrations non appliquées seront appliquées dans l'ordre chronologique

Rollback une migration

On peut rollback une migration via la commande yarn run dbMigrate down.

Sans aucun argument, la dernière migration appliquée sera rollback.
Avec un argument --name <NomDeLaMigration>, seule cette migration sera rollback
Avec l'argument --earliest, toutes les migrations appliquées seront rollback dans l'ordre anti-chronologique
Avec l'argument --force, une migration non présente dans les fichiers mais présente en base de données sera effacée (ça peut arriver si on se retrouve dans un état incohérent et qu'on veuille nettoyer la base de données)

Première migration ajoutée

J'ai aussi profité de cette PR pour ajouter la première migration archipelago-updateFilesType pour permettre de migrer le type des fichiers uploadés avant la version 0.6.0.

assemblee-virtuelle / archipelago