Illustration de l’utilisation de Mysql pour le stockage des données issues de l’apport des utilisateurs dans Emolgine.
Deux tables ont été générées ayant une structure voisine. La table emolgine_requetes et emolgine_annotation.
emolgine_requetes : objectif est de stocker la liste des requêtes exécutées dans Neo4J par utilisateur. Chaque requête est associée à un calcul de hash (sha256) stocké dans l’attribut qui permet de cumuler pour un même utilisateur une seule entrée et de pouvoir stocker à chaque exécution dans l’attribut performances un tableau (date — perf).
Structure de cette table :
+---------------+---------------------+------+-----+---------+---------------+
| Field | Type | Null | Key | Default | Extra |
+---------------+---------------------+------+-----+---------+---------------+
| id | bigint(20) unsigned | NO | PRI | NULL | auto_increment |
| user | varchar(255) | NO | | NULL | |
| checksum | varchar(255) | NO | | NULL | |
| requete | longtext | NO | | NULL | |
| performances | longtext | YES | | NULL | |
| accessibilite| varchar(20) | YES | | NULL | |
+---------------+---------------------+------+-----+---------+---------------+
Exemple de contenu
| 54 | useremolgine | 1ef2d5941c5b7757bdd4fd7766066abc843f95f9f0bc31aaaedc3ea8721c340d | MATCH (n:Molecule) RETURN n LIMIT 10 | [{"date": "2024-08-21 09:05:55", "perf": 0.008063077926635742}, {"date": "2024-08-21 09:06:10", "perf": "0.016541004180908"}] | perso |
| 55 | useremolgine | ca593a99549ed11ed8487bd5aee98c4d3902473e1bfc01cb3b168bf1ab7018cf | MATCH r=(mol:Molecule)-[:FIT]->(:Cluster_mol_site)-[:CFIT]->(:Site)-[:FROM]->(:Protein) WHERE mol.id STARTS WITH 'ABC' RETURN r LIMIT 200 | [{"date": "2024-08-21 09:06:36", "perf": 0.02539992332458496}, {"date": "2024-08-21 09:07:39", "perf": "0.025347948074341"}, {"date": "2024-08-21 09:52:16", "perf": "0.025094985961914"}] | perso |
| 56 | useremolgine | add52ca3f196593a76174c5ab564cc48bfc681d9ffcf8fbca0d4dc6ed7a82375 | MATCH (n1)-[r]->(n2) RETURN r, n1, n2 LIMIT 25 | [{"date":"2024-08-21 09:52:31","perf":0.02987384796142578}] | perso |
| 57 | ystroppa | ca593a99549ed11ed8487bd5aee98c4d3902473e1bfc01cb3b168bf1ab7018cf | MATCH r=(mol:Molecule)-[:FIT]->(:Cluster_mol_site)-[:CFIT]->(:Site)-[:FROM]->(:Protein) WHERE mol.id STARTS WITH 'ABC' RETURN r LIMIT 200 | [{"date":"2024-08-21 13:21:16","perf":0.02583479881286621}]
Calcul du hash pour la requête : pour le traitement de la requête, on supprime tous les espaces et on la transforme en majuscules pour calculer le code de hashage que l’on va stocker dans la table.
hash('sha256', strtoupper(preg_replace('/\s+/','',$requete)))
Illustration de la manipulation de ce type de table en SQL
Lecture
function requete_get($user,$checksum) {
global $wpdb,$table_name;
$data=$wpdb->get_row($wpdb->prepare("SELECT id FROM $table_name WHERE user like '$user' and checksum like '$checksum'"));
ecrire_log("verification presence de la requete ".json_encode($data));
return $data;
}
Modification :
A l’aide de l’instruction JSON_ARRAY_APPEND on peut ajouter directement dans la structure ARRAY la nouvelle entrée sous forme de documentation JSON sous la forme {“date”:value, “perf”:value};
function requete_update_perf($id,$performance, $datetime) {
global $wpdb,$table_name;
ecrire_log("requete_update_perf "." ".$id." ".$performance." ".$datetime);
$retour=$wpdb->query($wpdb->prepare("UPDATE $table_name SET performances=JSON_ARRAY_APPEND(performances, '$',JSON_OBJECT('date','$datetime','perf','$performance')) WHERE id like $id"));
ecrire_log("retour mise a jour ".$retour);
}