Bonjour,
Tenant compte de ces informations, j'ai utilisé plusieurs sortes de requêtes SQL, que je détaille ci-dessous.
Répartition des fichiers par code de statut :
SELECT statuscode, COUNT(1) AS Nb FROM mdl_plagiarism_compilatio_files
WHERE timesubmitted > UNIX_TIMESTAMP ('2021-09-01')
GROUP BY statuscode ORDER BY Nb DESC;
+------------+-------+
| statuscode | Nb |
+------------+-------+
| 202 | 16108 |
| 415 | 7957 |
| Analyzed | 3577 |
| 413 | 485 |
| 416 | 226 |
| 412 | 148 |
| In queue | 59 |
| pending | 37 |
| 418 | 36 |
| 404 | 9 |
+------------+-------+
Nombre de fichiers analysés mais dont le statut est incorrect (et
donc l'affichage dans Moodle ne fait pas apparaitre le taux de similitude) :
SELECT COUNT(1) AS Nb FROM mdl_plagiarism_compilatio_files
WHERE reporturl IS NOT NULL AND statuscode <> 'Analyzed'
AND timesubmitted > UNIX_TIMESTAMP ('2021-09-01');
Et correction de ces cas :
UPDATE mdl_plagiarism_compilatio_files SET statuscode = 'Analyzed'
WHERE reporturl IS NOT NULL AND statuscode <> 'Analyzed'
AND timesubmitted > UNIX_TIMESTAMP ('2021-09-01');
Ce qui permet de voir apparaitre dans Moodle le statut correct ainsi que le taux de similitude.
Ensuite, j'ai cherché à faire
ré-analyser les fichiers en erreur, afin une analyse à jour et correcte. Mais pour éviter de surcharger le
serveur Compilatio, j'ai effectué ces modifications par lots.
Sélection du nombre de fichiers en erreur (dans une période) :
SELECT COUNT(1) AS Nb FROM mdl_plagiarism_compilatio_files
WHERE statuscode IN ('412', '413', '414', '415', '416', '418')
AND timesubmitted BETWEEN UNIX_TIMESTAMP ('2022-07-01') AND UNIX_TIMESTAMP ('2022-09-01');
et modification de ces fichiers (pour une période) pour les remettre à analyser :
UPDATE mdl_plagiarism_compilatio_files SET statuscode = 'pending'
WHERE statuscode IN ('412', '413', '414', '415', '416', '418')
AND timesubmitted BETWEEN UNIX_TIMESTAMP ('2022-07-01') AND UNIX_TIMESTAMP ('2022-09-01');
et on suit le nombre restant à traiter chez Compilatio :
SELECT COUNT(1) AS Nb FROM mdl_plagiarism_compilatio_files
WHERE statuscode='pending'
AND timesubmitted BETWEEN UNIX_TIMESTAMP ('2022-07-01') AND UNIX_TIMESTAMP ('2022-09-01');
on attend que ça tombe à 0 avant de
relancer une autre période (en modifiant les dates).
J'ai donc découpé cela mois par mois pour ré-analyser tous les fichiers en erreur déposés depuis le 1er septembre 2021.
Une fois cela fait, j'ai relancé la première requête permettant d'avoir la répartition des statuts des fichiers, et constaté que la plupart des erreurs avaient disparues, hormis les codes 415 (type de fichier non supporté) qui restaient en très grand nombre.
Pour en savoir un peu plus, notamment sur les extensions utilisées, j'ai lancé :
SELECT RIGHT(filename, 4) AS Ext, COUNT(1) AS Nb FROM mdl_plagiarism_compilatio_files
WHERE statuscode='415' AND timesubmitted BETWEEN UNIX_TIMESTAMP ('2021-09-01') AND UNIX_TIMESTAMP ('2022-09-01')
GROUP BY Ext ORDER BY Nb DESC LIMIT 20;
Et j'ai effectivement constaté qu'il y a plein de fichiers .zip, .php, .java, .png, .rar, .sql, .jpg, .m4a... et qu'il est normal qu'ils ne soient pas analysés correctement.
Par ailleurs, afin de vérifier que les documents étaient bien migrés vers la v5 :
SELECT COUNT(1) AS Nb FROM mdl_plagiarism_compilatio_files
WHERE LENGTH (identifier) < 40
AND timesubmitted > UNIX_TIMESTAMP ('2021-09-01');
En toute logique, il n'en reste plus (dans toute la table) !
Séverin
