La déclaration porte sur les lectrices, pas sur les écrivaines¶
ClassementLectureEcritureTest#aucune_commande_n_est_sans_classementContexte¶
L'application graphique réserve le dossier de travail pour toute sa durée (VerrouWorkspace,
2731). La documentation de ce verrou nomme elle-même le cas qui l'a fait naître : « deux instances¶
graphiques, une IHM et une CLI, ou une restauration pendant un import ».
La CLI ne l'a jamais demandé. Un vigiechiro importer lancé pendant que l'application est ouverte
écrivait dans la même base, sans que rien ne l'en empêche ni ne le signale. Le verrou est
coopératif : il ne bloque personne, il refuse à qui le demande - et personne ne demandait.
Le lot 1 de #2720 avait construit le verrou ; les lots 4 et 5 ont travaillé la surface CLI sans le reprendre. Aucune cérémonie de lot ne pouvait voir le trou : il n'est visible que depuis les deux bouts à la fois.
Poser le verrou demande de savoir quelles commandes écrivent. Aucun signal mécanique ne le dit :
- le nom ne prouve rien -
metadonnees-passagerattrape et envoie des métadonnées sans que rien ne l'annonce, tandis qu'emplacementsécrit, mais ailleurs ; - le service appelé classe
lister-sitesparmi les écrivains,ServiceSitessachant écrire ; - l'analyse d'appels ne tranche pas non plus. Mesuré sur les 65 commandes avec ArchUnit, en
suivant les appels jusqu'aux primitives : elle rate
supprimer-siteet signalelister-carres, qui n'écrit qu'un CSV à l'emplacement demandé par l'utilisateur. Elle se trompe dans les deux sens, et un vérificateur qui se trompe vers le vert est pire que pas de vérificateur.
Décision¶
Le verrou se prend par défaut. Une commande s'en dispense en se déclarant lectrice, par
l'interface marqueur fr.univ_amu.iut.cli.LectureSeule.
Ce qui départage les deux sens de déclaration n'est pas leur précision - elles sont aussi faillibles l'une que l'autre - c'est le sens dans lequel une erreur se paie :
| Déclaration oubliée | Conséquence |
|---|---|
| une écrivaine, si on déclarait les écrivaines | son écriture échappe au verrou. Le défaut persiste en silence, et rien ne le dira |
| une lectrice, comme ici | sa consultation est refusée pendant que l'application est ouverte. Visible, gênante, sans danger - et signalée le jour même |
La liste des lectrices est aussi la plus stable : une commande qui lit le restera, alors qu'une commande qui se met à écrire ne rappellera à personne qu'il faut la déclarer.
« Lecture seule » veut dire : ne touche ni la base ni les dossiers du dossier de travail. Interroger le réseau, ou écrire hors du dossier de travail, reste de la lecture seule : le verrou protège le dossier de travail, pas le disque. La configuration d'amorçage en fait partie - elle vit dans le dossier de configuration et se protège toute seule, en s'écrivant d'un seul coup (#3507).
Cette frontière n'est pas une commodité, et elle a coûté un aller-retour. emplacements avait
d'abord été classée écrivaine, au motif qu'elle écrit la configuration d'amorçage ; sept tests ont
rougi en intégration continue. Le remède n'était pas de les isoler : la commande sert à repointer
le dossier de travail, et la verrouiller revient à refuser de déménager à qui déménage justement parce
que la place actuelle est occupée ou abîmée. CliVerrouWorkspaceTest fige ce cas.
Le refus est un RefusAvantEcriture, donc un code de sortie 2 : rien n'a été touché. Il est
traduit dans migrerPuisExecuter, car le gestionnaire d'exceptions de picocli ne voit que ce que lève
la commande - un refus né dans la stratégie d'exécution lui échappait et retombait en 1, « échec,
état incertain », ce qui était faux dans le sens inquiétant.
Ce que le garde vérifie, et ce qu'il ne vérifie pas¶
ClassementLectureEcritureTest exige que chaque commande soit classée : elle porte le marqueur,
ou elle figure dans la liste des écrivaines, tenue dans le test. Il vérifie aussi que cette liste ne
garde pas d'entrée périmée, qui ferait passer pour classée une commande renommée.
Il ne dit pas si le classement est juste. Il dit qu'un choix a été fait. C'est l'oubli silencieux qu'il rend impossible, pas l'erreur de jugement - et l'erreur de jugement, ici, se paie du bon côté.
Conséquences¶
- Une commande nouvelle arrive protégée : ne rien faire la verrouille. Le garde force alors sa conceptrice à trancher, plutôt que de la laisser hériter d'un défaut.
- Vingt-trois commandes sont déclarées lectrices, dont le groupe
apiet ses deux filles, en lecture seule par charte (ADR 3006). - La migration du schéma prend le verrou de son côté : une commande de lecture sur une base à mettre à jour peut donc être refusée. C'est voulu - mettre à jour le schéma est une écriture.
- Le verrou est réentrant dans un processus (
DETENUS) : un test qui le prendrait parVerrouWorkspace.prendreen rendrait celui de la CLI factice et ne prouverait rien. Les tests posent donc un verrou de fichier brut - et enbats, un verrou POSIX parfcntl, carflock(1)pose un verrou d'une autre famille, queFileChannel.tryLockignore : le test aurait été vert sans rien bloquer.