En premier lieu, il est plus que recommandé de consulter (et plutôt plusieurs fois qu’une) le document de préparation à la certification (« ZF Certification Study Guide« ) proposé sur le site de Zend. En 200 pages, vous aurez un condensé de tous les éléments requis. Autre document qui peut s’avérer utile, celui rédigé par Rob Allen (« Zend Framework Certification Refresher« ) qui est un rappel des notions principales de Zend Framework. Bien sûr, cela ne dispense pas de consulter la documentation officielle afin d’avoir connaissance de tous les détails de l’implémentation des classes.

Cela va sans dire, une pratique du framework est également essentielle. Et en particulier de toutes les classes concernant le MVC au sens large (accès à la base de données, aides de vues, formulaires…).

Très important, n’oubliez pas non plus de réviser les recommandations ZF sur le style du code PHP à adopter. Les classes pour l’utilisation des services web comme REST, SOAP et XML-RPC sont aussi à connaître.

Il est également obligatoire de retenir les différentes manières d’utiliser les méthodes. Très souvent, il est en effet possible pour un même paramètre de passer soit un objet soit un tableau ou bien encore le nom d’une classe. Vous devez connaître ces différents moyens de réaliser la même chose.

Pour résumer, cette certification ne m’a pas parue plus difficile (ni plus facile d’ailleurs) qu’une autre comme la certification Linux LPI. Les 90 minutes pour répondre aux 75 questions rédigées en anglais ne sont pas de trop, certaines questions nécessitent davantage de réflexion parce que les réponses proposées sont parfois très proches mais il n’y a pas de question destinée à « piéger » le candidat. Seul petit bémol, j’ai trouvé dommage de ne pas avoir la note finale, vous savez juste que vous avez obtenu la certification. Il serait intéressant d’avoir au moins une idée de son niveau et surtout de savoir dans quelles sections vous devez approfondir vos connaissances.

Il est très courant d’avoir à stocker une structure d’arbre dans une base de données. Par exemple, pour enregistrer l’organisation hiérarchique d’une entreprise ou bien pour représenter les catégories et sous-catégories des articles d’un site web.

La façon la plus simple de procéder est d’ajouter simplement à la table concernée un champ « identifiant_parent » qui servira à stocker l’identifiant du noeud parent. Ainsi, pour stocker l’arbre suivant :

      A
  ---------
  |       |
  B       C
        -----
        |   |
        D   E
      -----
      |   |
      F   G

nous aurions les enregistrements suivants :

identifiant    identifiant_parent
A                 NULL
B                 A
C                 A
D                 C
E                 C
F                 D
G                 D

Le noeud « A » qui est la racine de l’arbre n’a évidemment aucun parent c’est pourquoi l’identifiant du parent est dans ce cas mis à NULL.

Cette technique de représentation d’un arbre a comme avantage sa très grande simplicité. Elle a par contre l’inconvénient de nécessiter pour certains traitements l’envoi de plusieurs requêtes SQL de manière récursive. En effet, pour retrouver tous les noeuds enfants de « C », il n’est pas possible de le faire directement via une seule requête SQL. Il faut tout d’abord récupérer les enfants de « C » puis, pour chaque enregistrements trouvés, récupérer à leur tour leurs enfants.

Nous allons donc voir une autre méthode plus complexe mais aussi plus performante pour stocker dans une base SQL une structure d’arbre.

• Le ver sur la branche :

Au lieu d’utiliser la représentation classique d’un arbre, on peut aussi imaginer un arbre comme une imbrication d’ensembles. La racine est l’ensemble le plus grand qui regroupe tous les éléments, puis ses enfants sont des sous-ensembles plus petits qui regroupents leurs enfants, etc…

Graphiquement, l’arbre vu précédemment se représenterait ainsi :

------------------------ A ------------------------
|          B               |                      |
|                          |--------- C ----------|
|                          |                E     |
|                          |--- D ----            |
|                          | F     G |            |
|-------------------------------------------------|

L’ensemble « A » est le plus grand et contient « B » et « C » ainsi que leurs enfants. L’ensemble « C » contient à son tour « D » et « E » et leurs enfants, etc…

Pour représenter ces ensembles, il suffit d’utiliser cette fois deux champs de type entier que nous appellerons « gauche » et « droite ». Ils indiqueront en fait la grandeur de l’ensemble concerné. On peut aussi imaginer un ver qui parcourt l’arbre en partant de la racine et visite chaque noeud deux fois (une fois à gauche et une fois à droite). A chaque visite, il place dans le champ (gauche ou droite) la valeur d’un compteur qui augmente de 1 à chaque fois.

Pour représenter notre arbre, nous aurions donc cette fois-ci les enregistrements suivants :

identifiant    gauche    droite
A                1         14
B                2         3
C                4         13
D                5         10
E                11        12
F                6         7
G                8         9

Et pour revenir à notre précédente illustration graphique de l’arbre, cela donnerait :

         1 A 14
       -----------
       |         |
    2 B 3      4 C 13
            ----------
            |        |
          5 D 10  11 E 12
         --------
         |      |
       6 F 7  8 G 9

N.B. : pour le noeud  » B « , il faut lire  » 2 B 3  » (l’affichage n’est pas forcément correct…).

On voit d’emblée que cette représentation offre des propriétés intéressantes pour nos futures requêtes SQL. Par exemple :

- La racine est toujours le noeud dont l’enregistrement « gauche » est égal à la valeur 1.
- Pour sélectionner tous les enfants d’un noeud donné, il suffit de récupérer tous ceux dont le champ « gauche » est supérieur à la valeur du champ « gauche » de ce noeud et dont le champ « droite » est inférieur à la valeur du champ « droite » de ce noeud.
- Les feuilles (les noeuds sans enfants) sont les éléments dont la valeur du champ « droite » moins la valeur du champ « gauche » est égal à 1.

• Implémentation sous MySQL :

CREATE TABLE arbre (
  id BIGINT NOT NULL AUTO_INCREMENT,

  gauche BIGINT DEFAULT NULL,
  droite BIGINT DEFAULT NULL,

  ref CHAR(5) DEFAULT NULL,

  id_parent BIGINT NOT NULL DEFAULT 0,

  PRIMARY KEY (id),
  UNIQUE (gauche),
  UNIQUE (droite),
  KEY (ref),
  KEY (id_parent)
);

Nous retrouvons nos champs « gauche » et « droite ». Le champ « ref » contiendra la clef vers les données qui seront stockées dans une autre table. Ici, nous nous contenterons de placer dans ce champ une simple chaîne de caractères afin d’illustrer nos propos. Enfin, le champ « id_parent » indiquera l’identifiant du noeud parent. Ce dernier champ n’est pas obligatoire pour gérer l’arbre mais il permet toutefois d’avoir un lien direct vers le parent ce qui peut simplifier certaines requêtes.

• Procédure pour l’ajout d’un noeud :

delimiter //

CREATE PROCEDURE ajout (IN id_parent_noeud BIGINT, IN ref_noeud CHAR(1))
MODIFIES SQL DATA
BEGIN
DECLARE gauche_parent, droite_parent BIGINT DEFAULT NULL;

INSERT INTO arbre (ref, id_parent) VALUES (ref_noeud, id_parent_noeud);

SELECT gauche INTO gauche_parent FROM arbre WHERE id = id_parent_noeud;
SELECT droite INTO droite_parent FROM arbre WHERE id = id_parent_noeud;

UPDATE arbre SET gauche = gauche + 2
  WHERE gauche > gauche_parent
  ORDER BY gauche DESC;

UPDATE arbre SET droite = droite + 2
  WHERE droite >= droite_parent OR (droite > gauche_parent + 1 AND droite < droite_parent)
  ORDER BY droite DESC;

UPDATE arbre SET gauche = gauche_parent + 1, droite = gauche_parent + 2 WHERE ref = ref_noeud;
END;

delimiter ;

La procédure prend deux paramètres. « id_parent_noeud » indique l’identifiant du noeud parent pour le noeud qui sera ajouté. « ref_noeud » contient la clef vers les données associées au nouveau noeud.

On insère tout d’abord ce nouveau noeud avec les données passées en paramètres. Puis on décale les valeurs « gauche » et « droite » des autres noeuds de manière à pouvoir placer le nouveau noeud. On met enfin à jour les valeurs « gauche » et « droite » du nouveau noeud. Notez qu’avec la méthode de décalage choisie le noeud le plus récemment ajouté possède les indices « gauche » et « droite » les plus faibles parmi tous ses frères. A l’inverse, le noeud ajouté en premier aura toujours les indices « gauche » et « droite » les plus élevés parmis tous ses frères.

Pour utiliser cette procédure dans une requête SQL :

INSERT INTO arbre (id, gauche, droite, ref, id_parent) VALUES (1,1,2,'A',0);
CALL ajout(1,'B');
CALL ajout(1,'C');

On insère en premier lieu le noeud racine « A ». Puis on lui ajoute deux fils « B » et « C ».

Nous allons voir comment développer un client pour le logiciel serveur Memcached avec le langage Objective Caml. Le logiciel Memcached permet en résumé de stocker des données en mémoire vive ce qui offre des accès très rapides. Une valeur est simplement indexée par une clef unique qui est utilisée par le client pour écrire, modifier ou lire cette donnée. Memcached est typiquement utilisé pour stocker des valeurs temporaires afin de gérer un cache d’où son nom. Son protocole est relativement simple ce qui en fait un bon candidat pour une première approche du développement en Objective Caml.

Le code source complet est disponible dans cette archive.

• Protocole Memcached :

La documentation disponible sur le protocole donne un premier aperçu des fonctions qui seront nécessaires :

- Les commandes simples comme la demande de version du serveur ou le « flush_all » nécessitent simplement l’envoi d’une seule ligne de texte au serveur qui enverra en réponse une ligne de texte.

- Les commandes plus complexes comme les statistiques ou l’écriture d’une donnée nécessitent de gérer l’envoi ou la réception de plusieurs lignes.

- Il sera nécessaire de pouvoir vérifier si la réponse du serveur à une commande du client ne correspond pas à une erreur.

- Nous aurons évidemment besoin d’une fonction pour ouvrir et fermer la connexion au serveur Memcached.

- Chaque commande prévue par le protocole sera implémentée par une fonction dédiée.

• Typage :

Le protocole nous indique également les types à gérer. Il est par exemple souvent fait référence à des entiers non signés en 16, 32 ou 64 bits. Comme la notion d’entier non signé n’est pas disponible nativement en Objective Caml, nous allons gérer ces différents types par l’intermédiaire de modules dédiés.

Prenons l’exemple le plus simple qui est celui des entiers non signés 16 bits. La signature de ce module sera définie dans un fichier appelé « memcache_int16u.mli » :

	type t
	exception Overflow of t
	val zero : t
	val min : t
	val max : t
	val to_string : t -> string
	val of_string : string -> t
	val of_int : int -> t

Le type « t » correspondra au type Objective Caml natif pour stocker l’entier. En l’occurrence, pour les entiers non signés 16 bits, il s’agira du type « int ». L’exception « Overflow » sera levée si l’entier dépasse les limites. Ici ce sera le cas si le nombre est négatif ou bien dépasse la valeur 65535 (2^16 – 1).

On définie également les valeurs zéro (0), minimale (0) et maximale (65535). On aura également à notre disposition trois fonctions de conversions pour par exemple transformer une chaîne de caractères représentant un nombre vers le type entier non signé 16 bits.

Les trois modules dédiés à la gestion des entiers non signés auront cette même signature. Seule l’implémentation sera différente. Comme la signature de ce module reste très simple, il a été facile de la rédiger directement. Pour les signatures plus complexes, il est possible de générer automatiquement une première version à partir du fichier .ml d’implémentation grâce à l’option « -i » du compilateur Objective Caml.

Un autre type important correspond à la structure qui nous servira à stocker les informations pour la connexion au serveur :

	type connection = {
	  host: string; (** adresse IP du serveur *)
	  port: int; (** numéro de port *)
	  in_channel: in_channel; (** canal de communication entrant *)
	  out_channel: out_channel; (** canal de communication sortant *)
	};;

Un enregistrement de ce type sera passé en paramètre à toutes les fonctions qui auront besoin d’échanger des données avec le serveur Memcached.

• Implémentation :

Passons maintenant au développement des fonctions proprement dites. Nous en détaillerons uniquement certaines pour donner un aperçu du langage Objective Caml.

Prenons par exemple la fonction chargée de recevoir plusieurs lignes en provenance du serveur :

(**
  Reçoit plusieurs lignes du serveur.
  @param connection Informations pour la connexion (déjà ouverte).
  @return Une FIFO contenant les lignes dans l'ordre de réception + une chaîne de caractères concaténation des lignes reçues et séparées par \n.
*)
let receive_lines_from_server ~connection =
  (* c'est par le canal de communicatio entrant que notre client reçoit les données du serveur *)
  let in_channel = connection.in_channel in
  (* on créé une structure FIFO pour stocker les lignes reçues du serveur *)
  let queue_lines = Queue.create () in
  (* on créé un tampon qui stockera lui aussi les lignes reçues du serveur mais sous forme de chaîne de caractères *)
  let text_lines = Buffer.create 1024 in
  (* on créé une variable "l" (une référence sur une chaîne vide) qui servira à stocker une ligne reçue *)
  let l = ref "" in
  (* on définie une fonction récursive "one_line" qui servira à traiter une ligne *)
  let rec one_line () =
    (* on récupère la ligne courante qui provient du serveur *)
    l := input_line in_channel;
    (* on supprime les fins de lignes *)
    l := Str.global_replace regexp_trail_eol "" !l;
    (* si ce n'est pas la dernière ligne *)
    if (!l <> end_line) then (
      (* on stocke la ligne courante dans la FIFO et dans le tampon *)
      Queue.add !l queue_lines;
      Buffer.add_string text_lines (!l ^ "\n");
      (* on rappelle la fonction pour traiter la prochaine ligne *)
      one_line ();
    )
    (* plus de ligne à traiter, on peut renvoyer le résultat *)
    else (
      (queue_lines, Buffer.contents text_lines)
    )
  in
    (* il faut appeler une première fois la fonction "one_line" pour commencer le traitement *)
    one_line ()
;;

Notez que la variable « l » est une référence sur une chaîne vide dont la valeur est modifiée dans la fonction « one_line ». Pour assigner une nouvelle valeur à une référence, il est nécessaire d’utiliser le signe « := ». Et pour obtenir le contenu (la valeur) de la référence, on utilise le signe « ! » devant le nom de la variable.

La fonction renvoie un tuple (une liste de valeurs) dont le premier élément est la suite des lignes reçues du serveur. Il s’agit de la variable « queue_lines » qui est une file FIFO. Le deuxième élément renvoyé est une chaîne de caractères qui contient la concaténation des lignes reçues du serveur. Les deux éléments contiennent donc au final les mêmes données. L’intérêt de renvoyer ces données sous deux formes différentes est de pouvoir selon les besoins traiter la réponse du serveur soit comme une suite de lignes soit comme une chaîne de caractères.

Voyons ensuite la fonction qui envoie la commande pour stocker une valeur auprès du serveur :

(**
  Commandes de stockage d'une clef/valeur.
  @param cmd Commande (voir la section "Storage commands" du protocole).
  @param key Clef de la valeur.
  @param flag Valeur "flag" d'une commande de stockage (voir la section "Storage commands" du protocole).
  @param time Expiration.
  @param bytes Nb d'octets des données à stocker.
  @param data Les données à stocker.
  @param connection Informations pour la connexion (déjà ouverte).
  @raise Bad_answer_from_server Réponse inattendue du serveur.
  @return Indique si la valeur a été stockée ou pas.
*)
let storage ~cmd ~key ~flag ~time ~bytes ~data ~connection =
  (* on construit la commande de stockage à partir des paramètres *)
  let s = (cmd ^ " " ^ key ^ " " ^ (Int16u.to_string flag) ^ " " ^ (string_of_int time) ^ " " ^ (string_of_int bytes)) in
  (* on envoie la ligne au serveur *)
  let () = send_one_line_to_server ~connection ~s in
  (* et ensuite on envoie au serveur la donnée à stocker *)
  let s = Buffer.contents data in
  let () = send_one_line_to_server ~connection:connection ~s:s in
  (* le serveur doit nous retourner une réponse *)
  let answer = receive_one_line_from_server ~connection:connection in
  (* on vérifie que cette réponse ne correspond pas à une erreur *)
  let () = check_error_answer_from_server ~answer:answer in
  (* on examine ensuite cette réponse qui doit correspondre à une des réponses possibles pour la commande de stockage *)
  let new_value =
    match answer with
      | "STORED" -> Stored
      | "NOT_STORED" -> Not_stored
      | _ -> raise (Bad_answer_from_server answer)
  in
    (* la fonction retourne cette réponse sous forme d'un type "storage_answer" que nous avons défini *)
    new_value
;;

La fonction prend en paramètres toutes les données nécessaires au traitement qu’elle effectue. Notez que le caractère « ~ » au début de chaque paramètre indique que ce sont des paramètres nommés. C’est à dire que lorsque la fonction sera appelée, il sera possible d’indiquer ce nom pour chaque valeur de paramètre ce qui permet ainsi de s’affranchir du respect de l’ordre de définition des paramètres. La fonction peut ainsi être appelée de cette manière :

	storage ~connection:connexion ~flag:(Int16u.of_int 32) ~time:1219422874 ~bytes:1024 ~cmd:"commande" ~key:"clef" ~data:tampon

On peut voir que l’on rappelle pour chaque paramètre son nom défini lors de la déclaration de la fonction. Il n’est donc pas obligatoire de respecter le même ordre dans les paramètres. Si le nom des paramètres est suffisamment explicite, c’est également une manière de rendre plus clair le code.

Notez que le caractère « ^ » est utilisé pour la concaténation des chaînes de caractères. C’est l’équivalent du caractère « . » dans le langage PHP.

Pour finir, remarquez une construction très utilisée dans le langage Objective Caml qui est le « match ». Ici, cela permet de comparer la valeur de la variable « answer » avec les chaînes de caractères « STORED » et « NOT_STORED » et selon le cas de stocker dans « new_value » soit « Stored » soit « Not_stored ». Si la comparaison échoue, le défaut indiqué par le caractère « _ » est de lever l’exception « Bad_answer_from_server ». La construction « match » ne s’applique pas uniquement à des chaînes de caractères. Elle peut par exemple s’appliquer à des listes ou à un type défini dans le programme. Vous êtes invité à consulter la documentation du langage Objective Caml pour plus de détails.

Pour finir, voyons la fonction qui permet d’obtenir les statistiques globales du serveur :

(**
  Statistiques globales du serveur.
  @param connection Informations pour la connexion (déjà ouverte).
  @raise Bad_answer_from_server Si réponse inattendue ou si une des réponses n'est pas dans la liste "names_stats".
  @return Une liste de paires (nom, valeur) correspondant aux statistiques.
*)
let stats ~connection =
  (* on envoie la commande "stats" au serveur *)
  let s = "stats" in
  let () = send_one_line_to_server ~connection:connection ~s:s in
  (* on reçoit la réponse en plusieurs lignes de la part du serveur *)
  let (lines, answer) = receive_lines_from_server ~connection:connection in
  (* on doit au moins recevoir une ligne *)
  (* si ce n'est pas le cas, on lève une exception *)
  let () =
    if (Queue.length lines <= 0) then (raise (Bad_answer_from_server answer))
  in
  (* fonction qui traite une seule ligne des statistiques reçues *)
  let one_line acc l =
    (* les lignes sont de la forme "STAT <nom> <valeur>" *)
    let r = Str.regexp ("^STAT \\([^ ]+\\) \\(.+\\)") in
      (* si la ligne est au bon format *)
      if (Str.string_match r l 0) then (
        try
          (* on récupère la partie "nom" *)
          let name = Str.matched_group 1 l in
          (* on récupère la partie "valeur" *)
          let value = Str.matched_group 2 l in
          (* on vérifie que les clefs/valeurs reçues sont bien autorisées *)
          let () =
            if (not (List.mem_assoc name names_stats)) then (raise (Bad_answer_from_server answer))
          in
          (* conversion des valeurs en entiers non signés *)
          let new_value =
          let type_value = List.assoc name names_stats in
            match type_value with
              | Ts_32u _ -> Ts_32u (Int32u.of_string value)
              | Ts_64u _ -> Ts_64u (Int64u.of_string value)
              | Ts_string _ -> Ts_string value
              | Ts_2x_32u _ -> Ts_2x_32u value
            in
            (* on ajoute le tuple (nom, valeur) à la liste qui sera renvoyée par la fonction *)
              (name, new_value) :: acc
        with
          | Not_found -> raise (Bad_answer_from_server answer) (* une des lignes n'est pas au bon format *)
      )
      else (
        raise (Bad_answer_from_server answer) (* une des lignes n'est pas au bon format *)
      )
  in
    (* pour chaque ligne reçue du serveur, on appelle la fonction "one_line" *)
    Queue.fold (one_line) [] lines
;;

On peut voir que la fonction « one_line » a notamment comme paramètre une variable appelée « acc » (pour « accumulateur »). Ce type de paramètre est souvent présent en Objective Caml. Il permet en effet d’accumuler le résultat d’appels successifs à une fonction donnée. Ici, la fonction « one_line » est appelée autant de fois qu’il y a de lignes à traiter grâce à l’utilisation de la fonction « Queue.fold ». On peut également voir dans l’appel à cette fonction que l’accumulateur a comme valeur de départ une liste vide.

On retrouve aussi la construction « match…with » dont nous avons déjà parlé. Cette fois-ci, la comparaison porte sur les types d’entiers non signés que nous avions définis.

• Compilation « bytecode » :

Objective Caml offre deux modes de compilation :

- Un mode qui permet d’obtenir un exécutable natif, de la même manière que l’on obtiendrait un exécutable depuis des sources en langage C. L’avantage est de produire un programme avec de très bonnes performances. En contre-parti, ce programme fonctionnera uniquement sur la plate-forme (par exemple un système FreeBSD sur PC) pour lequel il a été compilé.

- Un mode « bytecode » qui produira un programme destiné à être exécuté par la machine virtuelle Objective Caml. C’est un mécanisme similaire à celui utilisé par le langage Java. L’exécution sera plus lente qu’avec un programme natif mais il ne sera plus dépendant de la plate-forme.

Vous trouverez dans l’archive contenant les sources un script shell indiquant les commandes pour compiler le code en mode « bytecode » et ainsi obtenir une librairie et un exécutable de démonstration.

Par exemple, pour compiler le fichier memcache_int16u.ml qui contient l’implémentation des entiers 16 bits non signés, la commande est la suivante :

	ocamlc -c memcache_int16u.ml

Ce qui produira un fichier objet « memcache_int16u.cmo ».

• Références :

Protocole Memcached : http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt

Site officiel Objective Caml : http://www.ocaml.org/

Nous allons voir comment éviter l’envoi inutile de requêtes SQL identiques lors de l’exécution d’un script PHP utilisant Zend Framework. L’idée est de mettre en cache le résultat de chaque nouvelle requête SQL. Pour ensuite être capable de renvoyer directement le résultat mis en cache dans le cas où les données de la base utilisées par cette requête n’ont pas été modifiées. En effet, si nous sommes capable de vérifier qu’aucun enregistrement des tables concernées par la requête n’a été modifié depuis la mise en cache, nous sommes certain de pouvoir renvoyer directement le résultat en cache puisque la sélection de données sera forcément identique. Attention toutefois, nous partons du principe que les requêtes ne comportent pas de conditions de sélection extérieures aux données elles-mêmes. Une requête qui comporterait par exemple une condition sur l’heure courante pourrait voir son résultat changer même si les données sur lesquelles portent la requête ne sont jamais modifiées. Il vous faudra donc veiller à utiliser à bon escient ce mécanisme de cache.

• Comment connaître la dernière date de modification des tables grâce aux triggers :

Considérons la table MySQL suivante :

CREATE TABLE utilisateur (
  id BIGINT NOT NULL AUTO_INCREMENT,
  nom VARCHAR(255) DEFAULT NULL,
  PRIMARY KEY (id)
);

Nous avons besoin de conserver la dernière date de modification de cette table. Pour cela, nous allons créer une autre table appelée « modif_table » qui aura la structure suivante :

CREATE TABLE modif_table (
  nom_table CHAR(255) DEFAULT NULL,
  maj TIMESTAMP,
  PRIMARY KEY (nom_table),
  KEY (maj)
);

Grâce aux triggers, nous allons sauvegarder dans cette table « modif_table » la date de dernière modification de notre table « utilisateur ». Le champ « nom_table » aura donc ici la valeur « utilisateur » et le champ « maj » la date et heure de la dernière modification.

Voyons maintenant les instructions MySQL pour mettre en place les triggers :

delimiter //
CREATE TRIGGER trig_apres_insert_utilisateur AFTER INSERT ON utilisateur FOR EACH ROW
BEGIN
  INSERT INTO modif_table (nom_table, maj) VALUES ('utilisateur', NOW()) ON DUPLICATE KEY UPDATE maj=NOW();
END;
//
CREATE TRIGGER trig_apres_update_utilisateur AFTER UPDATE ON utilisateur FOR EACH ROW
BEGIN
  INSERT INTO modif_table (nom_table, maj) VALUES ('utilisateur', NOW()) ON DUPLICATE KEY UPDATE maj=NOW();
END;
//
CREATE TRIGGER trig_apres_delete_utilisateur AFTER DELETE ON utilisateur FOR EACH ROW
BEGIN
  INSERT INTO modif_table (nom_table, maj) VALUES ('utilisateur', NOW()) ON DUPLICATE KEY UPDATE maj=NOW();
END;
//
delimiter ;

Pour chaque événement (insertion, modification et suppression d’un enregistrement) qui peut avoir pour effet de modifier les données de la table « utilisateur », la date de dernière modification est mise à jour dans la table « modif_table ». Notez l’utilisation d’une requête « INSERT…ON DUPLICATE » qui permet soit d’insérer un enregistrement s’il n’existe pas déjà soit de le mettre à jour s’il est déjà présent dans la table. En effet, l’enregistrement qui stocke la dernière modification pour la table « utilisateur » n’est pas obligatoirement déjà présent dans la table « modif_table ».

Nous pouvons maintenant tester si nos triggers fonctionnent comme nous le souhaitons. Après avoir créé les deux tables et les triggers vus précedemment dans une base de données, nous allons tout d’abord créer un premier enregistrement dans la table « utilisateur » :

mysql> INSERT INTO utilisateur (nom) VALUES ('Linus Torvald');
Query OK, 1 row affected (0.03 sec)

mysql> SELECT * FROM utilisateur;
+----+---------------+
| id | nom           |
+----+---------------+
|  1 | Linus Torvald |
+----+---------------+
1 row in set (0.00 sec)

mysql> SELECT * FROM modif_table;
+-------------+---------------------+
| nom_table   | maj                 |
+-------------+---------------------+
| utilisateur | 2008-08-19 22:14:53 |
+-------------+---------------------+
1 row in set (0.00 sec)

On peut constater que l’insertion de l’enregistrement « utilisateur » a provoqué la création d’un enregistrement dans la table « modif_table » comme nous l’avons défini grâce aux triggers.

Modifions ensuite l’enregistrement « utilisateur » :

mysql> UPDATE utilisateur SET nom='Donald Knuth' WHERE id=1;
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> SELECT * FROM modif_table;
+-------------+---------------------+
| nom_table   | maj                 |
+-------------+---------------------+
| utilisateur | 2008-08-19 22:18:19 |
+-------------+---------------------+
1 row in set (0.00 sec)

Là encore, nos triggers ont joué leurs rôles. Nous pouvons constater que la valeur du champ « maj » de la table « modif_table » a été modifiée pour refléter la mise à jour de l’enregistrement « utilisateur ».

Enfin, testons la suppression d’un enregistrement :

mysql> DELETE FROM utilisateur WHERE id=1;
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM modif_table;
+-------------+---------------------+
| nom_table   | maj                 |
+-------------+---------------------+
| utilisateur | 2008-08-19 22:22:21 |
+-------------+---------------------+
1 row in set (0.00 sec)

La date et l’heure de modification ont bien été modifiées.

• Définition de la classe Zend Framework

Nous avons donc maintenant tout ce qui nous est nécessaire en ce qui concerne la base de données. Il nous reste maintenant à l’utiliser sous Zend Framework.

Première étape, nous avons besoin d’une classe dédiée pour prendre en charge la gestion de la table « modif_table ». Nous avons uniquement besoin d’une méthode qui nous indiquera s’il est possible d’utiliser le cache. Plus précisément, une méthode qui nous indiquera si aucune des tables utilisées dans la requête de sélection n’a été modifiée depuis la mise en cache du résultat.

Voici donc notre classe qui sera enregistrée dans un fichier appelé « sql_modif_table.php » :

require_once('Zend/Db/Table/Abstract.php');
require_once('Zend/Db/Select.php');

class Sql_Modif_Table {
  // nom de la table SQL
  protected $_name = 'modif_table';
  // nom du champ clef primaire
  protected $_primary = 'nom_table';

  // indique si aucune table n'a été modifiée depuis un temps donné
  // renvoie faux si au moins une table a été modifiée, vrai sinon
  // le premier paramètre est un tableau qui donne les noms des tables
  // le deuxième paramètre est le temps unix utilisé pour la comparaison avec le temps de modification des tables
  public function no_update(array $table, $time) {
    // par défaut, renvoie FALSE (au moins une table a été modifiée)
    $r = FALSE;
    // il faut au moins une table et un temps
    if (is_array($table) && (count($table) > 0) && $time) {
      $db = Zend_Db_Table_Abstract::getDefaultAdapter();
      // on met entre quote le nom des tables
      $tab_quote_table = array();
      foreach ($table as $t) {
        array_push($tab_quote_table, $db->quote($t));
      }
      // on construit la partie IN de la requête
      $sql_in = implode(',', $tab_quote_table);
      $sql_in = '('.$sql_in.')';
      // on construit la requête
      $select = $db->select();
      $select->from($this->_name, array('nb' => 'COUNT(*)'))
                 ->where('nom_table IN '.$sql_in)
                 ->where('UNIX_TIMESTAMP(maj) <= ?', $time);
      $stmt = $select->query();
      $row = $stmt->fetch();
      if ($row) {
        $nb = $row['nb'];
        // si le nombre renvoyé par la requête est égal au nombre de tables,
        // cela signifie qu'aucune table n'a été modifiée depuis le temps passé en paramètre
        if ($nb == count($tab_quote_table)) {
          $r = TRUE;
        }
      }
    }
    return($r);
  }
}

Cette méthode « no_update() » construit une requête SQL à partir de ses paramètres afin de vérifier si une des tables contenues dans la variable « $table » a été modifiée après le temps (format Unix) indiqué dans la variable « $time ». Par exemple, si la méthode est appelée avec les paramètres suivants :

...
$table = array('table1', 'table2');
$time = '1219422874';
$r = $o->no_update($table, $time);
...

La requête SQL sera :

SELECT COUNT(*) AS nb FROM modif_table WHERE nom_table IN ( 'table1', 'table2' ) AND UNIX_TIMESTAMP ( maj ) <= '1219422874';

Deuxième étape, nous allons maintenant surcharger la méthode Zend_Db_Select::query() afin de faire en sorte que toutes les requêtes « SELECT » envoyées bénéficient du cache si cela est possible. Voici donc notre classe qui sera enregistrée dans un fichier appelé « db_select.php » :

require_once('Zend/Db/Select.php');
require_once('sql_modif_table.php');

class Db_Select extends Zend_Db_Select {

  // la méthode envoie la requête vers le serveur de base de données
  // seulement s'il n'est pas possible d'utiliser le cache
  private function query_cache($fetchMode) {
    // tableau qui stocke le resultat des requêtes
    // la clef du tableau est la signature MD5 de la requête SELECT
    static $cache_value = array();
    // tableau qui stocke la date et l'heure de l'envoi des requêtes
    // la clef du tableau est la signature MD5 de la requête SELECT
    static $cache_time = array();

    // signature MD5 de la requête
    $sql = $this->__toString();
    $signature = md5($sql);
    $r = null;
    // par défaut, n'utilise pas le cache
    $use_cache = false;
    if (isset($cache_value[$signature]) && isset($cache_time[$signature])) {
      // la requête a déjà été envoyée, on vérifie si l'on peut utiliser le résultat mis en cache
      $table_update = new Sql_Modif_Table;
      // on récupère la liste des tables sur lesquelles porte la requête
      $part_from_sql = $this->getPart(Zend_Db_Select::FROM);
      $tables_in_sql = array();
      foreach ($part_from_sql as $from) {
        $t = $from['tableName'];
        array_push($tables_in_sql, $t);
      }
      // peut-on utiliser le cache ?
      if ($table_update->no_update($tables_in_sql, $cache_time[$signature])) {
        // oui, donc le résultat renvoyé sera celui présent en cache
        $r = $cache_value[$signature];
        $use_cache = true;
      }
    }
    if (! $use_cache) {
      // le cache ne peut être utilisé
      $time_cache = time();
      // donc on envoie la requête SELECT à la base de données
      $r = parent::query($fetchMode);
      // et on stocke ce nouveau résultat dans le cache
      $cache_value[$signature] = $r;
      $cache_time[$signature] = $time_cache;
    }
    return($r);
  }

  // méthode surchargée afin d'utiliser la méthode avec cache
  public function query($fetchMode = null) {
    $r = $this->query_cache($fetchMode);
    return($r);
  }

}

Nous allons également surcharger la classe Zend_Db_Table_Abstract afin de disposer d’une classe qui interdit l’utilisation directe de la méthode Zend_Db_Table_Abstract::select(). Cette nouvelle classe sera stockée dans un fichier appelé « db_table.php » :

require_once('Zend/Db/Table/Abstract.php');

class Db_Table extends Zend_Db_Table_Abstract {

  public function insert(array $data) {
    return parent::insert($data);
  }

  public function update(array $data, $where) {
    return parent::update($data, $where);
  }

  public function delete(array $where) {
    return parent::delete($where);
  }

  // on interdit l'utilisation directe de cette méthode
  public function select() {
    die('Db_Table::select():Don\'t use this method !');
  }

}

• Intégration dans une application Zend Framework :

Si vous utilisez le modèle MVC que propose Zend pour votre application, les trois fichiers que nous avons vu précédemment seront typiquement à placer dans le répertoire « application/models/ ».

L’appel aux méthodes que nous avons définies se fera par exemple de la manière suivante :

...
$db = Db_Table::getDefaultAdapter();
$select = new Db_Select($db);
$select->from($this->tableName)
           ->where('champ = ?', $valeur);
$stmt = $select->query();
$row = $stmt->fetch();
...

Vous remarquerez l’utilisation des classes « Db_Table » et « Db_Select » que nous avons créées. De cette manière, nous sommes certain que les requêtes utiliseront le mécanisme de cache que nous avons mis en place.

• Pour aller plus loin…

Comme les données du cache sont stockées dans un tableau, le cache n’est actif que pendant l’exécution du script PHP. Il ne sera donc utile que si vous exécutez plusieurs fois les mêmes requêtes « SELECT » dans un même script. Ce qui est évidemment assez limité… Néanmoins, il serait tout à fait possible en modifiant uniquement la méthode Db_Select::query_cache() de rendre le cache persistant et ainsi de le partager pour tous les scrips PHP de votre application. Une possibilité intéressante serait par exemple de gérer ce cache avec le logiciel « memcached » qui permet de stocker en mémoire vive des données via un mécanisme client/serveur. Une librairie pour développer des clients « memcached » en PHP est disponible.

Par ailleurs, une bien meilleure implémentation serait d’utiliser la classe Zend_Cache proposée dans Zend Framework pour la gestion proprement dite du cache. Il serait ainsi possible d’utiliser les différents backends déjà disponibles et en particulier le backend « memcached ».

• Références :

Triggers sous MySQL : http://dev.mysql.com/doc/refman/5.0/fr/triggers.html

Documentation Zend Framework : http://framework.zend.com/

Memcached : http://www.danga.com/memcached/