[FEATURE] Supprimer la colonne "grainId" de la table "element-answers" (PIX-12459)

[reibecca]

🦄 Problème

Cette information n'est pas utilisée par l'équipe métier, nous n'avons donc pas le besoin de l'enregistrer.

🤖 Proposition

Faire une migration pour supprimer la colonne grainId de la table element-anwers de la BDD.

🌈 Remarques

On a choisi de mettre la colonne à nullable dans le down de la migration, sinon le rollback ne fonctionne pas dans le cas où il y a déjà des données dans la BDD.

💯 Pour tester

En local :

1. Dans le dossier api lancer la commande npm run db:migrate
2. Dans votre BDD, vérifiez que la colonne grainId de la table element-anwers n'existe plus
3. Lancer Pix App et aller sur le module didacticiel-modulix
4. Répondez aux questions et assurez vous que lorsque vous cliquez sur le bouton Vérifiez il n'y a pas d'erreur
5. Ensuite retournez dans votre terminal et exécutez la commande npm run db:rollback:latest
6. Retourner dans votre BDD et vérifiez que la colonne grainId de la table element-anwers est à nouveau présente

Sur la RA :

1. Vérifiez qu'il n'y a pas de regression en allant sur le module didacticiel-modulix
2. Répondez aux questions et assurez vous que lorsque vous cliquez sur le bouton Vérifiez il n'y a pas d'erreur

[pix-bot-github]

Une fois les applications déployées, elles seront accessibles via les liens suivants :

• App (.fr)
• App (.org)
• Orga (.fr)
• Orga (.org)
• Certif (.fr)
• Certif (.org)
• Junior
• Admin
• API
• Audit Logger

Les variables d'environnement seront accessibles via les liens suivants :

• scalingo front
• scalingo api
• scalingo audit-logger

[dlahaye]

5. Ensuite retourner dans votre terminal et exécutez la commande npm run db:rollback:latest

ça ne marchera pas 👉 Dans le fichier de migration > ici <, lors du scénario de test proposé, on fini avec une ou plusieurs lignes dans la table, et le fait que la colonne ne soit pas nullable génère une erreur SQL lors du rollback.

‼️ migration failed with error: alter table "element-answers" add column "grainId" varchar(255) not null - column "grainId" of relation "element-answers" contains null values

Réponse 1 heure plus tard:
On a choisi de mettre la colonne à nullable dans le down.

Une autre stratégie aurait été de gérer la rétro-compatibilité en deux PR distinctes:

• Une PR où on supprime les usages dans le code

Puis une version plus tard:

• Une PR avec la migration qui drop la colonne

[VincentHardouin]

Je suis vraiment pas convaincu de supprimer cette colonne, comme je n'étais pas là lors des points qui ont fait émergé ce ticket, je ne pense pas avoir tout le contexte.
Pour moi, avoir le grainId permet quand même d'avoir le contexte dans lequel est passé l'élément et ça me parait intéressant comme information, comme un élément est sensé être réutilisable.
On peut imaginer faire un élément de pré-module, et le même en fin de module. Si nous n'avons plus le grainId, alors l'analyse des résultats sera compliqué.
Même autre que dans le même module, si nous souhaitons voir si un élément fonctionne mieux dans un module où l'autre, cela nous permets de récupérer l'information sans faire le lien avec les passages et le module.

[VincentHardouin]

Je suis vraiment pas convaincu de supprimer cette colonne, comme je n'étais pas là lors des points qui ont fait émergé ce ticket, je ne pense pas avoir tout le contexte. Pour moi, avoir le grainId permet quand même d'avoir le contexte dans lequel est passé l'élément et ça me parait intéressant comme information, comme un élément est sensé être réutilisable. On peut imaginer faire un élément de pré-module, et le même en fin de module. Si nous n'avons plus le grainId, alors l'analyse des résultats sera compliqué. Même autre que dans le même module, si nous souhaitons voir si un élément fonctionne mieux dans un module où l'autre, cela nous permets de récupérer l'information sans faire le lien avec les passages et le module.

Pour le contexte : le métier ne souhaite pas réutiliser les éléments, ni les grains c'est donc OK de supprimer la colonne