Valery Fremaux

Hi fellows,

the 'richtext2' occurrence is symptomatic of a Moodle 2.0 code.

The issue you all got was that the distribution link on the Scheduler (now Scheduler pre-1.9) is erroneous and points to HEAD.

The HEAD code of scheduler is reworked for Moodle 2.0 for a little while,

The only working package and legitimate is now accessible through the Scheduler 1.9 entry to which I have enough write access to make it correct.

http://moodle.org/mod/data/view.php?d=13&rid=2732&filter=1

Apologize for the trouble, guys... 

Cheers.

As we can confirm,

the link published in the Scheduler Pre -1.9 is confusing. It routes to the HEAD CLS in which the code reworked for Moodle 2.0 is being prepared....

Please get the accurate package which is attached to Scheduler 1.9 record (mentionned above)

Thanks.

This is obviously the Moodle 2.0 version you got. I wonder how...

I'm checking the downloaded package.

The correct plugin bas entry is now : http://moodle.org/mod/data/view.php?d=13&rid=2732&filter=1

Plus généralement, vous posez ici le problème de la destruction de données dans un modèle de données complexe, relationnel et modulaire.

L'une des seules solutions à ce problème architecturalement, serait que chaque plugin fasse son propre nettoyage, ou que le noyau puisse demander à chaque plugin quelles sont les tables disposant d'une référence à un utilisateur et fournir le champ de cette référence (des requêtes comme ci-dessus peuvent alors être construites de manière systématique).

Le GROS problème est que cette pratique demanderait que TOUS les plugins la suive, y compris les contributifs, et que cette réponse soit CORRECTEMENT implémentée par tous les contributeurs de Moode.

Vous parlez d'un chantier....

Autres problèmes du même type :

- Impossible de supprimer totalement des enregistrements d'hôtes MNET contactés une fois.

- Impossible de supprimer des comptes utilisateurs importés via une communication MNET. 

A bientôt...

Il faut savoir que le nombre d'utilisateurs dans la table mdl_user n'est pas la plus grande source de charge dans la base de données.

L'une des sources les plus importantes est la croissance des tables message, message_read, forum_posts, forum_discussions, et éventuellement chat_message si les discussions en ligne sont très utilisées.

Mais surtout ce sont les tables mdl_log et mdl_mnet_log (dans le cas de l'utilisation du réseau MNET) qui croissent énormément.

Une bonne stratégie est de récupérer ces logs (dumper la table par exemple) si vous voulez les conserver, et nettoyer cette table en ne gardant que un à deux mois de traces.

Il est aussi possible après avoir supprimé des utilisateurs, d'exécuter la requete de nettoyage suivante :

Table mdl_log :

DELETE mdl_log WHERE userid IN (SELECT id FROM mdl_user WHERE deleted = 1)

Table des messages (message et message_read) :

DELETE mdl_message WHERE useridfrom IN (SELECT id FROM mdl_user WHERE deleted = 1) OR useridto IN (SELECT id FROM mdl_user WHERE deleted = 1)

Ces deux commandes SQL nettoyent correctement les messages et les traces de ces utilisateurs mais vous perdez évidemment ces traces.

Ces commandes de nettoyage peuvent être généralement construites pour d'autres tables, dès qu'un champ (souvent, "userid", ou "studentid" ou "teacherid" apparaît).

Il faut être bien sûr de ne pas voir réapparaître cette personne dans le futur...

Ces commandes peuvent être exécutées copiées telles que sur une installation standard via la console SQL de PhpMyAdmin.

Cheers.