Bonjour à tous,
Je suis actuellement en train de développer un outils de génération de flux rss à partir de la Base de Données d'une plateforme Moodle 1.8.1+ et je ne parviens pas à trouver de documentation détaillant la structure de la BD et le détail des champs. Sauriez-vous ou je pourrai trouver une telle documentation (si elle existe)?
Sinon je continue ma propre analyse des tables mais je ne comprends pas bien le format (bigint(10)) des dates par exemple pour le champ timecreated de la table mdl_course dont une valeur est 1182778086.
Comment passer de la valeur de ce champ à une date concrète?
Merci d'avance pour votre aide précieuse.
Cordialement.
Bonjour,
sans être spécialiste, je pourrais malgré tout fournir quelques indices...
La date est stockée sous forme de timestamp unix, et 1182778086 correspond au 25 juin 2007 à 9h28
Les commentaires de chaque table et champ de table peuvent se voir depuis le gestionnaire de la base de données interne de Moodle.
Je ne suis pas certain que cela te suffira...
sans être spécialiste, je pourrais malgré tout fournir quelques indices...
La date est stockée sous forme de timestamp unix, et 1182778086 correspond au 25 juin 2007 à 9h28
Les commentaires de chaque table et champ de table peuvent se voir depuis le gestionnaire de la base de données interne de Moodle.
Je ne suis pas certain que cela te suffira...
Merci pour ces précisions qui déjà m'aide un peu.
Ne me reste plus qu'a trouver comment convertir une date timestamp unix en date classique mais cela ne doit pas être bien sorcier
Si vous avez d'autres précisions sur la base de données n'hésitez pas à me les communiquer.
Merci
Ne me reste plus qu'a trouver comment convertir une date timestamp unix en date classique mais cela ne doit pas être bien sorcier
Si vous avez d'autres précisions sur la base de données n'hésitez pas à me les communiquer.
Merci
pour le schéma de la base de données à partir de 1.7 :
http://docs.moodle.org/en/Development:Database_Schema
Pour la conversion en PHP d'un timestamp, selon la culture moodle, on utilise la fonction userdate() comme ceci :
setLocale(LC_TIME, substr(current_language(), 0, 2));
$datetexte = userdate($timestamp);
La ligne supérieure permet de s'assurer que le PHP utilise les bonnes localisations et n'afficha pas la date uniquement en anglais. Il s'agit d'une fonction de PHP et non de Moodle.
La deuxième convertit le timestamp (un timestamp est un temps universel UNIX calculé à partir d'une date de référence au 1er Janvier 1970 à minuit, date avant laquelle le système d'exploitation Unix -- et donc le reste de l'univers -- n'était pas sensée exister 
- on appele cette date magique "The Epoch"). La date de référence est exprimée en secondes écoulées à partir de The Epoch, ce qui constitue bien un entier, mais qui va forcément devenir de plus en plus grand (!!) d'où l'idée d'utiliser les plus grand entiers stockables de la base de données.
Je rappelle pour le fun, -- ou pas -- que le bug de l'an 2000 était dû au fait que les années étaient codées sur deux chiffres décimaux. Si le temps est codé sur 32 bits : 2^32 secondes celà représente un comptage de ... 136 ans et des brouettes. D'où un bug à prévoir en 2106. Autre inconvénient : pas d'existence de comptage avant 1970. Il existe une autre raison qui fait que le comptage d'une date Unix ne peut actuellement dépasser Septembre 2035.
Avantage certain : on peut calculer des durées par simple différence.
Pour finir, le bigint stocke des entiers jusqu'à 18.446.744.073.709.551.615 soit 584942417355 ans. De quoi voir venir....
Merci pour ces précisions et ces deux lignes de codes qui remplacent à merveille ma fonction de 10 lignes pour la conversion de date 
J'avais cependant une autre question à vous soumettre :
Je cherche (toujours depuis la base de données) à lier un cours aux utilisateurs qui ont un rôle d'administrateur ou de teacher afin de récupérer les informations sur leur profil malheureusement je ne parvient pas à déterminer les champs me permettant de faire la liaison. Je pensais que les champs 'teacher', 'teachers', 'student', 'students' étaient une piste mais je constate qu'ils restent toujours à la valeur par défaut et je n'en comprend pas bien la signification (pour ne pas dire l'utilité).
Si vous avez des informations sur le sujet à me transmettre je vous en serait très reconnaissant.
Merci d'avance.
J'avais cependant une autre question à vous soumettre
Je cherche (toujours depuis la base de données) à lier un cours aux utilisateurs qui ont un rôle d'administrateur ou de teacher afin de récupérer les informations sur leur profil malheureusement je ne parvient pas à déterminer les champs me permettant de faire la liaison. Je pensais que les champs 'teacher', 'teachers', 'student', 'students' étaient une piste mais je constate qu'ils restent toujours à la valeur par défaut et je n'en comprend pas bien la signification (pour ne pas dire l'utilité).
Si vous avez des informations sur le sujet à me transmettre je vous en serait très reconnaissant.
Merci d'avance.
Non, en fait ce n'est pas du tout comme ça que la liaison est faite.
1. Les champs student, students, teacher, teachers, ne servent qu'à stocker la "traduction locale" des termes "étudiant", "étudiants", "enseignant"', "enseignants" qui sont inscrit par défaut dans un nouveau cours. Ceci permet de modifier l'affichage dans un certain nombre de messages et de sorties à l'intérieur d'un espace de cours. Il y a de fortes chances que ces champs disparaissent à terme, car le nouveau système de rôle induit que certains cours utiliseront des schémas plus complexes, mais pour l'instant, c'est la seule façon de changer ces libellés.
2. L'assignation d'un utilisateur à un cours se fait par un jeu de tables : prefix_role (définit un role), prefix_role_capabilities (enregistre les valeurs de capacités pour chacun des rôles, chacun des capacités et chacun des contextes (donc grosse table, car table d'association entre tous les roles définis, tous les contextes et chacune des innombrables capacités individuelles réparties dans les modules et le code plus central), prefix_role_assignement permet d'attribuer un rôle à un utilisateur dans un certain contexte. Chaque fois qu'on inscrit un utilisateur pour faire quelque chose dans un cours, un module ou ailleurs par l'onglet "Roles", c'est là que ça se passe.
Enfin, la table prefix_context enregistre tous les contextes connus. Le principe est d'enregistrer une association entre un "niveau de contexte" et un "id" d'élément, à ce niveau. Ainsi, pour le niveau site c'est le niveau 10. Pour un module d'activité, c'est le niveau 70. Le numéro d'instance qui y est associé désigne donc pour chaque niveau quelque chose de différent : pour le niveau 70, l'id qui est associé est l'id d'un enregistrement de la table prefix_course_modules qui liste les instances des activités dans tous les cours.
Si on résume :
prefix_user -> prefix_role_assignement -> prefix_role
|
-> prefix_context WHERE contextlevel = 50 -> course
Voilà la relation de données qui te permet de savoir qui a un des rôles "legacy" (traduisible par "rôle historique") dans un cours Moodle.
PS : Attention, ceci n'est valable que depuis la mise en place des rôles en 1.7
Merci beaucoup,
Voila qui éclaire ma lanterne!
Je devrais grâce à ces indications réussir à obtenir les différents user associés aux rôles important pour un cours. Je pense que j'aurai cherché longtemps de moi même avant de faire le lien entre toute ces tables...
Encore merci pour vos lumières et la rapidité de vos réponses!
Cordialement
Voila qui éclaire ma lanterne!
Je devrais grâce à ces indications réussir à obtenir les différents user associés aux rôles important pour un cours. Je pense que j'aurai cherché longtemps de moi même avant de faire le lien entre toute ces tables...
Encore merci pour vos lumières et la rapidité de vos réponses!
Cordialement
Pour revenir sur les variables unixtime il existe la fonction date() qui est très simple à utiliser ( parce qu'il n'y a pas que Moodle dans la vie ) http://fr2.php.net/manual/fr/function.date.php
Ou meme encore plus pratique on peut directement en MySQL récupérer une date à partir d'un champ UNIXTIME:
Ou meme encore plus pratique on peut directement en MySQL récupérer une date à partir d'un champ UNIXTIME:
FROM_UNIXTIME(unix_timestamp)
Retourne une représentation de l'argument unix_timestamp sous la forme 'YYYY-MM-DD HH:MM:SS' ou YYYYMMDDHHMMSS, suivant si la fonction est utilisé dans un contexte numérique ou de chaîne.
mysql>SELECT FROM_UNIXTIME(875996580);-> '1997-10-04 22:23:00' mysql>SELECT FROM_UNIXTIME(875996580) + 0;-> 19971004222300
Il me semble que l'avantage d'utiliser les fonctions de Moodle est que cela permet de prendre en compte automatiquement le fuseau horaire de l'utilisateur
Tout à fait exact Séverin. la fonction de Moodle intègre la localisation de l'utilisateur pour lui offrir des dates dans sa langue, sa locale et son fuseau. Les fonctions "legacy" du PHP ne proposent qu'un format "international" technique qui convient moins bien à un affichage "grand public" où du moins humanisé.
Je rappelle que la forme YYYY-MM-DD est une représentation anglosaxone d'une date qui n'est pas conforme aux différentes règles historiques de typographie des dates en Français : DD/MM/YYYY On admet tout juste l'affichage des heures de type montre à quartz : HH:MM:SS que les règles françaises préfèrent afficher HHhMM et SSsec.
Bonnes remarques. La fonction FROM_UNIXTIME() est surtout pratique quand on veut intéroger une base de donnée hors script php pour une meilleure lisibilité.
La fonction date() elle permet d'afficher la date au format que l'on veut.
Quant aux problèmes de fuseaux horaires, ils se posent plutot à la création d'un timestamp qu'à l'affichage.
La fonction date() elle permet d'afficher la date au format que l'on veut.
Quant aux problèmes de fuseaux horaires, ils se posent plutot à la création d'un timestamp qu'à l'affichage.