Archives de l’auteur : admin

PHP: echo vs print

Ces derniers temps en me baladant nonchalamment sur le Web, j’ai eu l’occasion de voir à de nombreuses reprises des « matches » entre echo et print, certains soutenant (fort heureusement, avec leurs benchmarks à l’appui) qu’echo était plus rapide que print. Nous allons voir ce qu’il en est de notre côté !

Echo et print

Echo n’est pas une fonction ! C’est officiellement une « structure du langage » (language construct) PHP.

Echo, lorsqu’on l’utilise avec des parenthèses, ne prend qu’un seul paramètre :

$prenom = 'Sebastien';
// avec des parenthèses
echo ("Bonjour, " . $prenom);

Notre unique paramètre ici est le résultat de la concaténation de la chaîne de caractères « Bonjour, » avec la variable $prenom qui contient la valeur Sebastien.

Les virgules nous permettent également le passage de plusieurs paramètres à echo :

$prenom = 'Sebastien';
echo 'Bonjour, ', $prenom, ' !';

Faisons un savant mélange de tout ça :

$prenom = 'Sebastien';
echo "Salut, " . ($prenom . " Ferrandez"), ", ça va ?";

Print n’est pas non plus une fonction, et ce même si print retourne une valeur entière (constante, toujours égale à 1). Print est une aussi construction du langage plus proche de la fonction qu’echo puisqu’elle renvoie une valeur mais la comparaison s’arrête là.

C’est parfaitement inutile, mais de fait rien ne vous interdit de faire le branchement conditionnel suivant :

$prenom = 'Sebastien';
if (1 === print("Bonjour")) {
    echo ",$prenom";
}

ou bien, puisque print renvoie 1 et que 1 == true avec l’égalité dite classique :

$prenom = 'Sebastien';
if (print("Bonjour")) {
    echo ",$prenom";
}

Un benchmark maison

Pour valider la prévalence de l’un de ces language constructs sur l’autre, rien ne vaut un test ! Je suis horripilé par les gens qui propagent des légendes urbaines du développement sans apporter la preuve de ce qu’ils répètent bêtement (« telle fonction est plus rapide que telle autre », « telle chose c’est le Mal ! », « telle autre chose n’est pas optimisée ») !

Voici le programme trivial qui nous sert pour nos tests :

$time_start = microtime(true);

for ($i=0; $i<10000; $i++) {
   print "test";
}

$time_end = microtime(true);
$time = $time_end - $time_start;

echo PHP_EOL . "$time secondes\n";

Evidemment, pour tester echo, vous prendrez soin de remplacer l’appel à print par echo !
Voici la version de php CLI que j’ai utilisé pour mener ces petites investigations sous GNU/Linux Debian sid :

PHP 5.4.4-14 (cli) (built: Mar  4 2013 14:08:43) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

L’idée ici était de faire des boucles avec un nombre d’itérations décuplé. Voici les résultats de ces expérimentations :

100 impressions du mot test :
echo : 0.00029110908508301 secondes
print : 0.00029802322387695 secondes

1000 impressions du mot test :
echo : 0.0025129318237305 secondes
print : 0.0025389194488525 secondes

10000 impressions du mot test :
echo : 0.025437831878662 secondes
print : 0.027919054031372 secondes

100000 impressions du mot test :
echo : 0.30710697174072 secondes
print : 0.23741006851196 secondes

1 million d’impressions du mot test :
echo : 2.6142749786377 secondes
print : 2.5098519325256 secondes

10 millions d’impressions du mot test :
echo : 27.915874958038 secondes
print : 33.695736885071 secondes (quasiment 5 secondes de plus !)

Ces valeurs sont des valeurs moyennes, calculées sur l’ensemble des 5 tests lancés dans chacun des cas et pour chaque language construct. Ce qu’on peut observer à la lumière de ces tests empiriques c’est qu’effectivement, echo est plus rapide en terme de temps d’exécution que print. Cependant, la tendance s’inverse dans certains cas, notamment ici lorsque le nombre d’itérations croît pour atteindre un million d’itérations. La tendance initiale se retrouve sur des nombres très élevés d’itérations (ici, 10 millions).

En conclusion

Nous avons pu vérifier avec quelques exemples concrets que oui, echo est plus rapide que print. Evidemment, nous le voyons d’autant plus que nous poussons ces deux language constructs dans leurs derniers retranchements, avec un nombre d’itérations épouvantable (qui fait ça en pratique, hein ?).

J’ai tendance à penser que lorsqu’on en est arrivé à tenter de gagner des millisecondes sur un appel à une fonction ou un language construct PHP, c’est qu’on n’a plus rien à faire au niveau de la qualité du code produit et malheureusement, l’expérience m’a souvent montré qu’avant de s’attacher à optimiser des appels comme ceux-ci, les développeurs feraient mieux de s’attacher à produire du code de qualité (conforme aux principes SOLID, par exemple) !

Quelques liens

Documentation PHP : echo
PHP Benchmark http://www.phpbench.com/ [anglais]

Introduction à MongoDB

Laisser un commentaire

Dans le cadre des cours de bases de données que j’enseigne au CNAM, j’ai décidé pour ma dernière séance de l’année 2013-2013 de faire une présentation de MongoDB à mes élèves.

Sans aller trop en détail dans la technique (on n’y parle pas de sharding, de map-reduce ou de GridFs), l’idée était ici de leur présenter cet aspect des bases de données qui trouve de plus en plus d’écho dans la communauté des développeurs d’applications en ligne.

Nous avons passé l’année à parler de schéma conceptuel, d’E/R, de DDL, de DML, il me fallait aussi présenter une vision alternative des bases de données car connaître l’état de l’art technique est, en ce qui me concerne, une qualité requise chez tout concepteur qui prétend l’être.

Vous pouvez télécharger cette présentation au format PDF.

MySQL et InnoDB : activer les fichiers au niveau table avec innodb_file_per_table

5 réponses

Fichiers de base d’InnoDB

Par défaut, votre configuration pour les tables utilisant le moteur InnoDB avec MySQL est la suivante :

un fichier ibdata1 constamment alimenté est créé
deux fichiers de log (ib_logfile0 et ib_logfile1) sont crées

Vous pouvez les voir en faisant :

sebastien.ferrandez@sebastien$ ls -l /var/lib/mysql
total 28736
-rw-rw---- 1 mysql mysql 18874368 mai   21 10:17 ibdata1
-rw-rw---- 1 mysql mysql  5242880 mai   21 10:17 ib_logfile0
-rw-rw---- 1 mysql mysql  5242880 mai   20 15:58 ib_logfile1

Evidemment, il faudra au besoin modifier le chemin si vous avez customisé votre configuration MySQL. Le problème de ce fichier ibdata1 en mode append est qu’il a tendance à grossir très vite et à atteindre des tailles problématiques (de nature à remettre en cause le bon fonctionnement de MySQL) : sur ma machine locale, le mien faisait 3.4G ! Il m’a fallu dumper mes bases de données à des fins de sauvegarde, faire en sorte de ne plus avoir ce fichier monolithique mais plusieurs (par base de données et par table), redémarrer MySQL et rejouer mon script SQL pour remettre en place les données dont j’avais besoin rapidement.

Pour effectuer ce découpage propre par table, nous allons nous servir de la directive de configuration innodb_file_per_table. Comme je le disais plus haut, celle-ci n’est pas activée par défaut :

mysql> SHOW VARIABLES LIKE 'innodb_file_per_table';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_file_per_table | OFF   |
+-----------------------+-------+

Pour l’activer, il vous suffit d’en faire mention dans votre fichier my.cnf (situé par défaut sur mon installation dans /etc/mysql/my.cnf), dans la section réservée à mysqld (par exemple du côté du commentaire « Fine-tuning ») et évidemment il vous faudra redémarrer le démon mysqld pour prendre en compte ce changement.

Voici l’option de configuration à rajouter :

[mysqld]
#
# * Fine Tuning
#
innodb_file_per_table   = 1

Vous pouvez également écrire tout simplement « innodb_file_per_table », ceci fonctionnera. Redémarrez ensuite le service MySQL :

sudo service mysql restart

Connectez-vous en ligne de commande à votre MySQL et retapez la commande donnée ci-dessus, vous devriez avoir du nouveau :

mysql> SHOW VARIABLES LIKE 'innodb_file_per_table';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_file_per_table | ON    |
+-----------------------+-------+
1 row in set (0.00 sec)

Bien ! Notre modification est donc bien prise en compte ! Si je crée une nouvelle base de données et une nouvelle table :

mysql> create database lolcats; use lolcats;
Query OK, 1 row affected (0.00 sec)

Database changed
mysql> create table cat(id tinyint unsigned primary key, name varchar(20), age tinyint unsigned);
Query OK, 0 rows affected (0.04 sec)

Je retrouve bien tout ça dans mon répertoire MySQL :

sebastien.ferrandez@sebastien$ sudo ls -l /var/lib/mysql/lolcats/
total 116
-rw-rw---- 1 mysql mysql  8614 mai   21 10:44 cat.frm
-rw-rw---- 1 mysql mysql 98304 mai   21 10:44 cat.ibd
-rw-rw---- 1 mysql mysql    65 mai   21 10:43 db.opt

C’est bien le signe que le découpage « un fichier par table » est désormais en place !

Bénéficier du découpage avec une base de données déjà implantée

Si vous avez déjà une base de données et que vous vous apercevez qu’ibdata1 a grossi et qu’il est temps de passer à un fichier par table, procédez comme suit :

Créez un répertoire s’apprêtant à recueillir votre sauvegarde :

sebastien.ferrandez@sebastien:$ mkdir -p $HOME/mysql/backups/avant_filepertable

Faites une sauvegarde de l’intégralité de vos données :

sebastien.ferrandez@sebastien:$ mysqldump -u root -p --all-databases > $HOME/mysql/backups/avant_filepertable/all_databases.sql

Arrêtez le démon MySQL :

sebastien.ferrandez@sebastien:~$ sudo service mysql stop
[ ok ] Stopping MySQL database server: mysqld.

Naturellement, rajoutez votre option dans my.cnf :

[mysqld]
#
# * Fine tuning
#
innodb_file_per_table

Redémarrez MySQL :

sebastien.ferrandez@sebastien:~$ sudo service mysql start
[ ok ] Starting MySQL database server: mysqld ..
[info] Checking for tables which need an upgrade, are corrupt or were 
not closed cleanly..

A l’issue de ce redémarrage, pensez à valider la bonne prise en compte de cette option à l’aide du SHOW VARIABLES montré un peu plus haut dans ce billet.
Supprimez vos fichiers (à vous de voir si vous souhaitez conserver les logs) :

sebastien.ferrandez@sebastien:$ sudo rm -fr /var/lib/mysql/*

Installez de nouvelles tables système. Attention, les messages que j’ai mis en gras nécessitent votre attention !

sebastien.ferrandez@sebastien:$ sudo /usr/bin/mysql_install_db
Installing MySQL system tables...
OK
Filling help tables...
OK

To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system

PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:

/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h sebastien password 'new-password'

Alternatively you can run:
/usr/bin/mysql_secure_installation

which will also give you the option of removing the test
databases and anonymous user created by default.  This is
strongly recommended for production servers.

Je vous conseille de passer par :

sudo /usr/bin/mysql_secure_installation

Voici les options que j’ai personnellement choisi :

Change the root password? [Y/n] n
 ... skipping.

Remove anonymous users? [Y/n] n
 ... skipping.
Disallow root login remotely? [Y/n]
 ... Success!

Remove test database and access to it? [Y/n]
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reload privilege tables now? [Y/n]

Ré-injectez vos données sauvegardées dans votre base qui maintenant sait découper par table :

sebastien.ferrandez@sebastien:~$ mysql -u root -p < $HOME/mysql/backups/avant_filepertable/all_databases.sql

Et validez que les tables que vous avez recrée se trouvent bien dans les répertoires correspondant à vos bases de données :

sebastien.ferrandez@sebastien:~$ sudo ls -l /var/lib/mysql/lolcats
total 116
-rw-rw---- 1 mysql mysql    65 mai   22 09:31 db.opt
-rw-rw---- 1 mysql mysql  8556 mai   22 10:02 cat.frm
-rw-rw---- 1 mysql mysql 98304 mai   22 10:02 cat.ibd

La table cat que j’ai crée se retrouve bien dans le répertoire correspondant à la base de données lolcats dont elle fait partie, l’opération est un succès !

Kit de premiers secours

Problèmes pouvant survenir au shutdown du démon MySQL

Si jamais vous n’arrivez pas à stopper MySQL, il s’agit sans doute d’un problème lié à l’utilisateur ‘debian-sys-maint’ du à la suppression des tables.
Voici comment le résoudre :

Récupérez d’abord le mot de passe courant de cet utilisateur (c’est une installation locale, je vous donne le mot de passe sans crainte) :

sebastien.ferrandez@sebastien:$ sudo grep password /etc/mysql/debian.cnf
password = JZe6ZMa9bMK4aqfm

Ensuite mettez-lui les bons privilèges dans votre ligne de commande MySQL :

mysql> GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY 'JZe6ZMa9bMK4aqfm' WITH GRANT OPTION;
Query OK, 0 rows affected (0.00 sec)

Changer le mot de passe root

Pour mettre p@$sW0rd! comme mot de passe à l’utilisateur root

mysqladmin -u root password p@$sW0rd!

Pour aller plus loin…

http://dev.mysql.com/doc/refman/5.0/fr/innodb-configuration.html
http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html (anglais)

MongoDB : un exemple de map-reduce

1 réponse

Le concept de map-reduce (on lit parfois les termes de paradigme de programmation ou de design pattern associés à map-reduce) n’a rien de nouveau : il s’inspire grandement des principes de base de la programmation fonctionnelle (i.e, par usage de fonctions mathématiques).

Comme son nom l’indique, map-reduce se compose de deux fonctions :

map, qui passe à reduce une clé et des données à traiter
reduce qui, pour chaque clé donnée par map, va opérer une réduction sur les données en provenance de map selon une logique que vous allez devoir écrire.

Map-reduce a connu un renouveau avec l’apparition des data stores de très grande capacité (on parle ici en pétaoctets) sur le web et doit en grande partie son retour sous les feux de la rampe à Google qui s’en est servi (et s’en sert toujours) pour distribuer/paralléliser les traitements, sur des clusters de machines. Le principe est simple: découper un gros problème en plusieurs petits, résolus par distribution à des nœuds fils (réducteurs) qui ensuite remontent le résultat de ces opérations aux nœuds de niveau supérieur, et ce récursivement jusqu’à remonter au la racine de l’arbre, qui a initié le calcul et en récupère donc le résultat final.

Ici nous n’aurons par cette notion de master nodes / worker nodes car nous travaillons sur une seule instance de MongoDB, située sur un seul serveur (ma machine) et non sur une architecture basée sur des shards ou des replica sets.

Image provenant de http://www.pal-blog.de/

Image provenant de PAL-Blog [http://www.pal-blog.de]

Map traverse tous les documents de votre collection MongoDB et va pousser des infos à reduce selon une clé définie. Passons à la pratique sans plus tarder…

Notre collection de test

Nous allons constituer une collection dénommée commandes et qui va contenir les commandes passées sur notre site web. Ces commandes seront évidemment des documents dont la structure est la suivante :

userid : l’identifiant de l’utilisateur à l’origine de la commande
date : la date de passage (ou de validation, pourquoi pas) de la commande
codepost : le code postal de la ville de résidence de l’utilisateur
articles : la liste des articles commandés (il y en a autant que souhaité)
totalttc : le prix TTC de la totalité de la commande
totalht : le prix HT de la totalité de la commande
tva : le montant de TVA applicable à la commande

sebastien.ferrandez@sebastien:~$ mongo
 MongoDB shell version: 2.0.6
 connecting to: test
>db.createCollection('commandes');
 { "ok" : 1 }
>show collections;
 commandes
 system.indexes

>db.commandes.insert({userid: 54845, date: new Date("Apr 28, 2013"), codepost:13100, articles:[{id:1,nom:'livre',prix:29.90}, {id:9, nom:'eponge', prix:2.90}], totalttc:32.80, tva:5.38, totalht:27.42});

>db.commandes.insert({userid: 54846, date: new Date("Apr 29, 2013"),codepost:13290, articles:[{id:45,nom:'robinet',prix:69.90}, {id:9, nom:'laitx6', prix:9.90}], totalttc:79.80, tva:13.08, totalht:66.72});

>db.commandes.insert({userid: 54847, date: new Date("Apr 30, 2013"),codepost:13008, articles:[{id:76,nom:'clavier',prix:49.90}, {id:2, nom:'fromage', prix:1.50}], totalttc:51.40, tva:8.42, totalht:42.98});

>db.commandes.insert({userid: 54848, date: new Date("Apr 28, 2013"),codepost:13600, articles:[{id:2987,nom:'presse',prix:2}], totalttc:2, tva:0.33, totalht:1.67});

>db.commandes.insert({userid: 54848, date: new Date("Apr 29, 2013"),codepost:13600, articles:[{id:2988,nom:'presse',prix:5.90}], totalttc:5.90, tva:0.97, totalht:4.93});

>db.commandes.insert({userid: 54848, date: new Date("Apr 30, 2013"),codepost:13600, articles:[{id:3989,nom:'presse',prix:1.20}], totalttc:1.20, tva:0.20, totalht:1});

>db.commandes.insert({userid: 54847, date: new Date("Apr 25, 2013"),codepost:13008, articles:[{id:2987,nom:'presse',prix:2}], totalttc:2, tva:0.33, totalht:1.67});

Structure du JSON

Voici la structure de l’un de nos documents :

{
    "_id": ObjectId("517fb463b53bb7169584f3c7"),
    "userid": 54847,
    "date": ISODate("2013-04-29T22:00:00Z"),
    "codepost": 13008,
    "articles": [
        {
            "id": 76,
            "nom": "clavier",
            "prix": 49.9
        },
        {
            "id": 2,
            "nom": "fromage",
            "prix": 1.5
        }
    ],
    "totalttc": 51.4,
    "tva": 8.42,
    "totalht": 42.98
}

Le JavaScript de notre map-reduce

Maintenant, nous allons écrire le map-reduce qui va opérer sur ces données; notre but est d’afficher, par code postal, le chiffre d’affaire généré par notre site en ligne. Créons donc un fichier mapred.js qui contiendra notre MR :

use commandes;

map = function() {
	emit(this['codepost'], {totalttc: this['totalttc']});
	};

reduce = function(cle, valeur) {
			var s = {somme : 0};
			valeur.forEach(function(article) {
				s.somme += article.totalttc;
			});
			return s;
		};

db.commandes.mapReduce(map, reduce, {out:'total_cmdes_par_ville'});

db.total_cmdes_par_ville.find();

And…action !

Nous injectons notre fichier JS dans Mongo

sebastien.ferrandez@sebastien:~$ mongo < /tmp/mapred.js

Et voici le résultat produit :

MongoDB shell version: 2.0.6
connecting to: test
function () {
    emit(this.codepost, {totalttc:this.totalttc});
}
function (cle, valeur) {
    var s = {somme:0};
    valeur.forEach(function (article) {s.somme += article.totalttc;});
    return s;
}
{
        "result" : "total_cmdes_par_ville",
        "timeMillis" : 33,
        "counts" : {
                "input" : 7,
                "emit" : 7,
                "reduce" : 2,
                "output" : 4
        },
        "ok" : 1,
}
{ "_id" : 13008, "value" : { "somme" : 53.4 } }
{ "_id" : 13100, "value" : { "totalttc" : 32.8 } }
{ "_id" : 13290, "value" : { "totalttc" : 79.8 } }
{ "_id" : 13600, "value" : { "somme" : 9.1 } }
bye

La fonction map va émettre (emit) des paires clé/valeur sur lesquelles reduce va travailler. Pour faire simple, reduce va faire la somme de tous les montants TTC des commandes pour un code postal donné. Une collection est créée pour abriter le résultat de l’exécution de map-reduce : nous avons décider de la nommer total_cmdes_par_ville. Elle est persistante, elle ne sera pas détruite une fois que vous vous déconnectez du shell MongoDB.

MongoDB : les bases pour bien débuter (3/3)

1 réponse

Revenons sur la collection MongoDB qui nous sert d’exemple depuis le début et effectuons quelques opérations de mise à jour élémentaires. Voici donc pour rappel à quoi ressemble notre collection :

sebastien.ferrandez@sebastien:~$ mongo
MongoDB shell version: 2.0.6
connecting to: test
> show dbs;
admin   0.203125GB
gens    0.203125GB
local   (empty)
> use gens;
switched to db gens
> db.gens.find();
{ "_id" : ObjectId("517a850cb1d6ce34f91af2d1"), "nom" : "ferrandez" }
{ "_id" : ObjectId("517a851eb1d6ce34f91af2d2"), "nom" : "ferrandez", "prenom" : "léo" }
{ "_id" : ObjectId("517a856bb1d6ce34f91af2d4"), "nom" : "ferrandez", "prenom" : "maïa", "age" : 6 }

Opérations de mise à jour

Avec inc

Supposons qu’il nous faille mettre à jour l’âge d’une personne : aujourd’hui c’est l’anniversaire de Maïa, elle a 7 ans ! Voici plusieurs façons de faire : tout d’abord nous incrémentons la clé age de nos documents pour lesquels age est supérieur à 5.

db.gens.update({ age:{$gt: 5}}, {$inc: {age: 1}});

Avec set

Nous ciblons uniquement le prénom

db.gens.update({ prenom: "maïa"}, {$set: {age: 7}});

Nous faisons un mélange des deux précédentes requêtes :

db.gens.update({ age:{$gt: 5}}, {$set: {age: 7}});

Opérations de suppression

Suppression par ObjectId

> db.gens.find();
{ "_id" : ObjectId("517a850cb1d6ce34f91af2d1"), "nom" : "ferrandez" }
{ "_id" : ObjectId("517a851eb1d6ce34f91af2d2"), "nom" : "ferrandez", "prenom" : "léo" }
{ "_id" : ObjectId("517e33cf4937f8d068f9e9aa"), "nom" : "ferrandez", "prenom" : "maïa", "age" : 7 }
> db.gens.remove( {"_id": ObjectId("517e33cf4937f8d068f9e9aa")});
> db.gens.find();
{ "_id" : ObjectId("517a850cb1d6ce34f91af2d1"), "nom" : "ferrandez" }
{ "_id" : ObjectId("517a851eb1d6ce34f91af2d2"), "nom" : "ferrandez", "prenom" : "léo" }

Suppression par champ quelconque

Supprimons tous les gens qui s’appellent « ferrandez » :

> db.gens.find();
{ "_id" : ObjectId("517a850cb1d6ce34f91af2d1"), "nom" : "ferrandez" }
{ "_id" : ObjectId("517a851eb1d6ce34f91af2d2"), "nom" : "ferrandez", "prenom" : "léo" }
> db.gens.remove({nom: 'ferrandez'});
> db.gens.find();

Notez que cette fois-ci je n’ai pas mis de guillemets autour de la clé (nom) et j’ai mis des apostrophes autour du nom pour que vous voyez bien qu’il n’est pas obligatoire de mettre tout ça entre guillemets systématiquement !

Suppression de la première occurrence seulement

En mettant justOne à 1 (le premier paramètre), seul le premier document satisfaisant aux critères sera supprimé :

> db.gens.find();
{ "_id" : ObjectId("517e36c14937f8d068f9e9ab"), "nom" : "ferrandez", "prenom" : "maïa", "age" : 7 }
{ "_id" : ObjectId("517e36e54937f8d068f9e9ac"), "nom" : "ferrandez", "prenom" : "sébastien" }
> db.gens.remove({nom: 'ferrandez'}, 1);
> db.gens.find();
{ "_id" : ObjectId("517e36e54937f8d068f9e9ac"), "nom" : "ferrandez", "prenom" : "sébastien" }

Suppression de l’intégralité des documents d’une collection

> db.gens.remove();

Voilà ! Pour ceux d’entre vous qui ont déjà des connaissances en langage SQL, vous avez les bases pour débuter avec MongoDB. Nous allons bientôt rentrer en détail dans le fonctionnement de MongoDB et en particulier nous attarder sur l’aspect dénormalisation !

MongoDB : les bases pour bien débuter (2/3)

2 réponses

Dans le billet précédent, nous avons vu quelques unes des requêtes DDL nous permettant de manipuler les structures élémentaires de MongoDB, comme les bases de données, les collections et les documents. L’heure est maintenant venue de requêter sur nos données !

Le kit MongoDB, qu’on reçoit à toutes les confs (source http://xenodesystems.blogspot.mx/)

Notre jeu de données de démarrage

Il est très simple :

> db.gens.insert({"nom":"ferrandez"});
> db.gens.insert({"nom":"ferrandez", prenom: "léo"});
> db.gens.insert({"nom":"ferrandez", prenom: "maïa", age:6});
> db.gens.find();
{ "_id" : ObjectId("517a850cb1d6ce34f91af2d1"), "nom" : "ferrandez" }
{ "_id" : ObjectId("517a851eb1d6ce34f91af2d2"), "nom" : "ferrandez", "prenom" : "léo" }
{ "_id" : ObjectId("517a856bb1d6ce34f91af2d4"), "nom" : "ferrandez", "prenom" : "maïa", "age" : 6 }

MongoDB est schema-less (prononcez « skimaless »), nous pouvons donc très bien insérer des documents qui n’ont pas la même structure, regardez bien nos trois documents, ils ne comportent pas le même nombre de champs !

Poser des index

Vous le savez, pour que vos requêtes aient un temps d’exécution satisfaisant (surtout si elle sont appelées fréquemment), il est absolument nécessaire qu’elles s’appuient sur des index. MongoDB dispose d’index au niveau des collections (l’équivalent des tables en SQL). Le champ _id est indexé par défaut et il est impossible de le supprimer.

Sur un seul champ

Pour poser un index sur le champ nom dans l’ordre ascendant (1, ce sera -1 pour DESC) :

db.gens.ensureIndex({nom:1});

Les index composés

Pour poser un index sur les champs nom ET prenom (ASC tous les deux) :

db.gens.ensureIndex({nom:1, prenom:1});

Comme en SQL, si vos requêtes se basent sur prenom, l’index ne sera pas utilisé !
Si vous requêtez sur le nom ou sur le nom ET le prénom, celui-ci sera sollicité.

Les index uniques

Rien de plus simple :

db.gens.ensureIndex({nom:1}, {unique: true});

Ici en réalité la pose de cet index va échouer car notre champ nom contient les mêmes valeurs :

> db.gens.ensureIndex({nom:1}, {unique: true});
E11000 duplicate key error index: gens.gens.$nom_1  dup key: { : "ferrandez" }

Voir les index d’une collection

db.gens.getIndexes();
[
        {
                "v" : 1,
                "key" : {
                        "_id" : 1
                },
                "ns" : "gens.gens",
                "name" : "_id_"
        },
        {
                "v" : 1,
                "key" : {
                        "nom" : 1
                },
                "ns" : "gens.gens",
                "name" : "nom_1"
        },
        {
                "v" : 1,
                "key" : {
                        "nom" : 1,
                        "prenom" : 1
                },
                "ns" : "gens.gens",
                "name" : "nom_1_prenom_1"
        }
]

Supprimer un index

On va supprimer l’index nommé ‘nom_1_prenom_1’ :

> db.gens.dropIndex('nom_1_prenom_1')
{ "nIndexesWas" : 3, "ok" : 1 }
> db.gens.getIndexes();
[
        {
                "v" : 1,
                "key" : {
                        "_id" : 1
                },
                "ns" : "gens.gens",
                "name" : "_id_"
        },
        {
                "v" : 1,
                "key" : {
                        "nom" : 1
                },
                "ns" : "gens.gens",
                "name" : "nom_1"
        }
]

Nous voyons qu’il a été effectivement supprimé (et nous voyons aussi au passage qu’un index est posé par défaut par MongoDB sur _id).

Les requêtes

Sur une seule valeur

Cherchons toutes les personnes qui ont 6 ans :

> db.gens.find({age:6});
{ "_id" : ObjectId("517a856bb1d6ce34f91af2d4"), "nom" : "ferrandez", "prenom" : "maïa", "age" : 6 }

Cherchons toutes les personnes qui s’appellent « ferrandez » :

> db.gens.find({nom:"ferrandez"});
{ "_id" : ObjectId("517a850cb1d6ce34f91af2d1"), "nom" : "ferrandez" }
{ "_id" : ObjectId("517a851eb1d6ce34f91af2d2"), "nom" : "ferrandez", "prenom" : "léo" }
{ "_id" : ObjectId("517a856bb1d6ce34f91af2d4"), "nom" : "ferrandez", "prenom" : "maïa", "age" : 6 }

Sur deux valeurs

Cherchons toutes les personnes qui ont 6 ans et qui s’appellent « ferrandez » :

> db.gens.find({nom:"ferrandez", age:6});
{ "_id" : ObjectId("517a856bb1d6ce34f91af2d4"), "nom" : "ferrandez", "prenom" : "maïa", "age" : 6 }

Avec des opérateurs de comparaison

Cherchons tous les « ferrandez » qui ont plus de 6 ans (gt = greater than)

> db.gens.find({nom:"ferrandez", age: {$gt: 6}});

Cherchons tous les « ferrandez » qui ont moins de 6 ans (lt = less than)

> db.gens.find({nom:"ferrandez", age: {$lt: 6}});

Ces deux requêtes ne ramènent aucun résultat, ce qui n’est pas le cas des suivantes avec l’égalité…

> db.gens.find({nom:"ferrandez", age: {$lte: 6}});
{ "_id" : ObjectId("517a856bb1d6ce34f91af2d4"), "nom" : "ferrandez", "prenom" : "maïa", "age" : 6 }
> db.gens.find({nom:"ferrandez", age: {$gte: 6}});
{ "_id" : ObjectId("517a856bb1d6ce34f91af2d4"), "nom" : "ferrandez", "prenom" : "maïa", "age" : 6 }

L’équivalent du IN SQL

Les gens dont l’âge est 6, 7 ou 8 :

> db.gens.find({age: {$in: [6, 7, 8]}});
{ "_id" : ObjectId("517a856bb1d6ce34f91af2d4"), "nom" : "ferrandez", "prenom" : "maïa", "age" : 6 }

Les expressions régulières (regexp)

Les gens dont le nom commence par la lettre f :

> db.gens.find({nom:/^f/});
{ "_id" : ObjectId("517a850cb1d6ce34f91af2d1"), "nom" : "ferrandez" }
{ "_id" : ObjectId("517a851eb1d6ce34f91af2d2"), "nom" : "ferrandez", "prenom" : "léo" }
{ "_id" : ObjectId("517a856bb1d6ce34f91af2d4"), "nom" : "ferrandez", "prenom" : "maïa", "age" : 6 }

MongoDB : les bases pour bien débuter (1/3)

2 réponses

Le but de ce billet est d’effectuer une première incursion dans l’univers MongoDB en voyant les commandes de bases dans le shell mongo et en faisant un parallèle avec ce qui existe dans le monde du SQL. Nous allons commencer en manipulant les bases : bases de données, collections et documents. Le but n’est pas de se noyer d’emblée dans l’architecture interne de Mongo (le sharding, les replica sets, etc.) mais d’attaquer d’emblée des choses concrètes !

L’emblème de MongoDB

Installation de MongoDB sur GNU Linux Debian
Nous allons faire les choses proprement au lieu d’insérer à la sauvage dans le fichier sources.list. Vous devez évidemment être sudoer pour effectuer ceci :

echo 'deb http://downloads-distro.mongodb.org/repo.fr.ian-sysvinit dist 10gen' > /tmp/mongodb.list
sudo cp /tmp/mongodb.list /etc/apt/sources.list.d/
rm /tmp/mongodb.list

sudo apt-get update
sudo apt-get install mongodb-10gen

A l’issue de l’installation, le serveur MongoDB doit être démarré automatiquement (le daemon mongod pour être plus précis).

Les principales commandes

Lancer le shell

Tout part de là ! En tapant « mongo » vous devriez y accéder car /bin doit être dans votre PATH. Si vous rencontrez des problèmes, lancez

/usr/bin/mongo

Quitter le shell

Rien de plus simple: faites donc Ctrl+C (ce bon vieux SIGINT !) ou tapez exit à l’invite, vous sortirez du shell.

Obtenir le numéro de version

Les données concernant votre installation apparaissent sous la forme d’un objet JSON, la commande a exécuter est en gras :

> db.runCommand({buildinfo: 1});
{
        "version" : "2.0.6",
        "gitVersion" : "nogitversion",
        "sysInfo" : "Linux z6 3.8-trunk-amd64 #1 SMP Debian 3.8.3-1~experimental.1 x86_64 BOOST_LIB_VERSION=1_49",
        "versionArray" : [
                2,
                0,
                6,
                0
        ],
        "bits" : 64,
        "debug" : false,
        "maxBsonObjectSize" : 16777216,
        "ok" : 1
}

Lister les bases de données

La commande permettant de faire ça est show dbs.

sebastien.ferrandez@sebastien:~$ mongo
MongoDB shell version: 2.0.6
connecting to: test
> show dbs;
local   (empty)

Comme je viens d’installer MongoDB, rien d’étonnant à ce qu’aucune base de données n’apparaisse ! Il est possible d’obtenir davantage d’informations en utilisant la base de données admin dont l’usage est réservé comme son nom l’indique à l’admin.

> use admin
switched to db admin
> db.runCommand({listDatabases: 1});
{
        "databases" : [
                {
                        "name" : "local",
                        "sizeOnDisk" : 1,
                        "empty" : true
                }
        ],
        "totalSize" : 0,
        "ok" : 1
}

Créer une collection

La collection en langage MongoDB est l’équivalent de la table en relationnel, on les crée soit en y insérant le tout premier document (l’équivalent du tuple en relationnel) soit en exécutant la commande suivante :

> db.createCollection('gens');
{ "ok" : 1 }

Insérer un document dans une collection

Notre collection s’appelle gens, insérons-y un premier document :

db.gens.insert( { nom: "ferrandez", prenom:"sebastien", age: 35 } );

Lister les documents contenus dans une collection

Pour faire l’équivalent d’un SELECT * FROM gens, j’utilise la commande find sans paramètres :

> db.gens.find();
{ "_id" : ObjectId("517941f3b12e1948c04f6d5e"), "nom" : "ferrandez", "prenom" : "sebastien", "age" : 35 }

Insérons un nouveau document et observons le changement dans le find :

> db.gens.insert( { nom: "ferrandez", prenom:"sandrine", age: 34, sexe:"F" } );
> db.gens.find();
{ "_id" : ObjectId("517941f3b12e1948c04f6d5e"), "nom" : "ferrandez", "prenom" : "sebastien", "age" : 35 }
{ "_id" : ObjectId("51794334b12e1948c04f6d5f"), "nom" : "ferrandez", "prenom" : "sandrine", "age" : 34, "sexe" : "F" }

Notez que, contrairement à une table, le nombre de champs n’est pas contraint par l’intention du schéma, en effet mon deuxième document a un champ de plus que le premier : sexe.
Dans les objets JSON que j’enregistre, un champ _id est déterminé par MongoDB. Il est évidemment tout à fait possible de forcer le sien :

> db.gens.insert( { _id: 10, nom: "ferrandez", prenom:"christophe", age: 40 } );
> db.gens.find();
{ "_id" : ObjectId("517941f3b12e1948c04f6d5e"), "nom" : "ferrandez", "prenom" : "sebastien", "age" : 35 }
{ "_id" : ObjectId("51794334b12e1948c04f6d5f"), "nom" : "ferrandez", "prenom" : "sandrine", "age" : 34, "sexe" : "F" }
{ "_id" : 10, "nom" : "ferrandez", "prenom" : "christophe", "age" : 40 }

Il est possible de manipuler des identifiants auto-incrémentés mais si vous insistez pour utiliser ce mécanisme offert par certains SGBDR comme MySQL c’est peut-être que vous avez une vision trop « relationnelle » de vos données ! Si toutefois vous persistiez à vouloir bénéficier de ce mécanisme, vous trouverez le lien à la fin de ce billet.

Supprimer une collection

Il vous faut utiliser drop, comme en SQL !

> db.gens.drop();
true

Supprimer une base de données

Deux manières de procéder, en faisant un use pour se connecter à la base de données à effacer :

> show dbs;
admin   0.203125GB
gens    0.203125GB
local   (empty)
> use gens;
switched to db gens
> db.runCommand({dropDatabase: 1});
{ "dropped" : "gens", "ok" : 1 }
> show dbs;
admin   0.203125GB
local   (empty)

ou bien en exécutant directement :

> db.gens.runCommand({dropDatabase: 1});
{ "dropped" : "gens", "ok" : 1 }

Pour aller plus loin…

Au sujet des identifiants auto-incrémentés : La documentation MongoDB (anglais)

Doctrine : les migrations avec le bundle DoctrineMigrationsBundle (3/3)

Laisser un commentaire

Voici la dernière partie de mon billet concernant les migrations Doctrine et le bundle associé.

Les relations des entités Doctrine

Nos élèves ont une relation avec leur filière. Nous en avons parlé au tout début lorsque nous définissions les cardinalités :

un élève a une seule filière
une filière a 0 ou plusieurs élèves

Il va nous falloir définir ceci au niveau de nos entités Doctrine. Nous allons donc « tirer un fil » entre nos entités Eleve et Filiere. Doctrine a des moyens de mettre ça en place et nous allons voir comment ceci se matérialise avec les annotations, que nous avons choisi de privilégier lorsque nous avons généré nos entités.

Entre Eleve et Filiere, il y a une relation de un à plusieurs (one to many en anglais). Nous la voulons bi-directionnelle dans le sens où nous souhaitons pouvoir à partir d’un élève récupérer sa filière et, à partir d’une filière, récupérer ses élèves. Dans l’entité Eleve, nous sommes du côté plusieurs de la relation (car plusieurs élèves correspondent à une filière). Voici comment nous allons nous servir des annotations Doctrine :

   /**
     * @ORM\ManyToOne(targetEntity="Filiere", inversedBy="eleves")
     * @ORM\JoinColumn(name="filiere_id", referencedColumnName="id", nullable=false)
     **/
    private $filiere;

Nous définissons une variable d’instance privée filiere qui va aider Doctrine à stocker la filière d’un élève (il n’y en a qu’une possible, souvenez-vous). La cible de la relation que nous sommes en train de décrire dans l’entité Eleve est l’entité Filiere, c’est ce que nous dit targetEntity. Le inversedBy qui suit signifie que de l’autre côté de la relation (dans l’entité Filiere) nous trouverons l’attribut chargé de gérer cette relation sous le nom d’eleves (notez bien le pluriel car de l’autre côté de la relation nous aurons plusieurs élèves pour notre filière). JoinColumn décrit la manière physique dont cette relation va exister. En lisant, vous devinez que dans notre table nous allons avoir un champ rajouté suite à l’écriture de cette relation qui va identifier une filière pour un élève, que ce champ s’appellera filiere_id et qu’il référencera une colonne appelée id…Vous voyez déjà venir gros comme une maison la contrainte d’intégrité référentielle. Le nullable=false signifie qu’il faut obligatoirement une filière à un élève ; là aussi vous devez imaginer que cette clause entraînera la présence d’un NOT NULL dans le schéma relationnel.

Du côté de l’entité Filiere, nous avons l’annotation Doctrine suivante pour la variable d’instance eleves dont nous avons déjà parlé :

     /**
     * @ORM\OneToMany(targetEntity="Eleve", mappedBy="filiere")
     **/
    private $eleves;

    public function __construct()
    {
        $this->eleves = new ArrayCollection;
    }

Nous prenons la relation dans l’autre sens – « un vers plusieurs » – parce qu’une filière a plusieurs élèves. Voilà pourquoi cette fois c’est one to many en lieu et place du many to one qu’on trouvait dans Eleve. La cible, c’est bien Eleve et l’attribut qui va servir c’est bien filiere (private $filiere). Dans Eleve nous avions inversedBy, dans Filiere nous avons mappedBy. Doctrine détermine le côté « possesseur » de la relation par inversedBy et l’autre côté (« inverseur ») par mappedBy.

Comme nous avons potentiellement plusieurs élèves pour une filière, nous allons avoir à gérer plusieurs objets. Pour ce faire, Doctrine nous propose son type ArrayCollection, que vous allez pouvoir utiliser en faisant :

use Doctrine\Common\Collections\ArrayCollection;

Notre variable d’instance privée eleves sera de ce type et nous l’initialiserons dans le constructeur de notre classe.

Nous avons construit notre première relation au niveau objet ! L’heure est venue de mettre notre schéma de bases de données à jour avec tout cela ! Allons-y !

app/console doctrine:migrations:diff

Ouvrons le fichier ainsi généré pour vérifier que notre relation est bien en place :

$this->addSql("ALTER TABLE eleve ADD filiere_id INT NOT NULL");
$this->addSql("ALTER TABLE eleve ADD CONSTRAINT FK_ECA105F7180AA129 FOREIGN KEY (filiere_id) REFERENCES filiere (id)");
$this->addSql("CREATE INDEX IDX_ECA105F7180AA129 ON eleve (filiere_id)");

Ce que nous envisagions est effectivement arrivé, nous avons bel et bien une contrainte d’intégrité référentielle posée entre la table eleve et la table filiere !

Lançons maintenant la migration :

app/console doctrine:migrations:migrate

Notre table eleve a bien un champ en plus : filiere_id !

sebastien.ferrandez@sebastien:~/migrations$ mysql -u root -p -e 'use exercice; desc eleve'
Enter password: 
+------------+-------------+------+-----+---------+----------------+
| Field      | Type        | Null | Key | Default | Extra          |
+------------+-------------+------+-----+---------+----------------+
| id         | int(11)     | NO   | PRI | NULL    | auto_increment |
| nom        | varchar(40) | NO   |     | NULL    |                |
| prenom     | varchar(40) | NO   |     | NULL    |                |
| age        | int(11)     | NO   |     | NULL    |                |
| filiere_id | int(11)     | NO   | MUL | NULL    |                |
+------------+-------------+------+-----+---------+----------------+

Occupons-nous ensuite des cours: un cours a des relations avec salle, enseignant et filière, en fait cours est au centre de tout…Quelles sont-elles exactement ? Reprenons ce que nous avions établi :

une filière est composée d’un ou plusieurs cours
un cours n’a qu’un seul et unique enseignant mais un enseignant a un ou plusieurs cours
un cours se tient dans une seule salle à un moment donné et une salle peut abriter plusieurs cours. On peut très bien créer un cours sans salle car il arrive qu’on ne puisse décider de suite dans quelle salle il se tiendra. Elle sera rajoutée plus tard.

Les relations nous apparaissent évidentes. Un lien de type « un à plusieurs » existe entre cours et enseignant (« un à plusieurs » dans le sens enseignant → cours et « plusieurs à un » dans le sens inverse). Il en va de même pour les salles ou les filières. La seule différence réside en le fait qu’un cours a forcément un enseignant ou une filière alors qu’il n’a pas forcément de salle (on peut le créer sans salle pour lui en affecter une quand on a consulté le planning des salles et qu’on en a trouvé une de disponible). Nous allons donc nous retrouver à ajouter des annotations de type ManyToOne dans notre entité Cours.

    /**
     * @ORM\ManyToOne(targetEntity="Filiere", inversedBy="cours")
     * @ORM\JoinColumn(name="filiere_id", referencedColumnName="id", nullable=false)
     **/
    private $filiere;

    /**
     * @ORM\ManyToOne(targetEntity="Salle", inversedBy="cours")
     * @ORM\JoinColumn(name="salle_id", referencedColumnName="id")
     **/
    private $salle;

    /**
     * @ORM\ManyToOne(targetEntity="Enseignant", inversedBy="cours")
     * @ORM\JoinColumn(name="enseignant_id", referencedColumnName="id", nullable=false)
     **/
    private $enseignant;

Vous noterez que salle est le seul endroit où nullable est à sa valeur par défaut, c’est à dire true et qu’il sera donc possible d’enregistrer un cours sans salle. Dans la mesure où nous avons pour un cours soit 0 (pour une salle) soit un (enseignant, filière) inutile ici d’utiliser les ArrayCollection comme c’était le cas pour matérialiser la relation filière/élève.
Dans chacune de ces entités cibles nous auront une variable d’instance nommée cours, c’est aussi ce que nous disent ces annotations.

Dans l’entité Salle :

    /**
     * @ORM\OneToMany(targetEntity="Cours", mappedBy="salle")
     **/
    private $cours;

    public function __construct()
    {
        $this->cours = new ArrayCollection;
    }

Ici par contre une salle est susceptible d’accueillir plusieurs cours (NFA057 le jeudi soir, NFA053 le mardi), la notion de collection a ici du sens. Idem pour les enseignants :

    /**
     * @ORM\OneToMany(targetEntity="Cours", mappedBy="enseignant")
     **/
    private $cours;

    public function __construct()
    {
        $this->cours = new ArrayCollection;
    }

Ou encore Filiere :

    /**
     * @ORM\OneToMany(targetEntity="Cours", mappedBy="filiere")
     **/
    private $cours;

Vous avez remarqué que le champ mappedBy de l’annotation pointe vers la variable d’instance correspondante dans l’entité Cours. Dans le cas de Filiere, l’entité avait déjà une instanciation de la classe ArrayCollection dans son constructeur, nous devons en rajouter une autre pour les cours, comme fait dans les autres entités, plus haut, ce qui donnera :

public function __construct()
    {
        $this->cours = new ArrayCollection;
        $this->eleves = new ArrayCollection;
    }

Une fois que nous avons mis nos relations dans nos 4 entités, il nous reste à exécuter une migration !

app/console doctrine:migrations:diff
app/console doctrine:migrations:migrate

feront apparaître les contraintes d’intégrité référentielle entre la table cours et enseignant, salle et filiere.

Maintenant que nous avons établi notre architecture objet avec nos entités, regardons avec MySQL Workbench à quoi ressemble notre schéma et surtout s’il satisfait à toutes les contraintes que nous avons énoncées au début du présent document :

En naviguant à travers les relations, nous sommes sûrs que nous avons effectué du bon travail car elles correspondent en tous points à ce que nous souhaitions.

Au sujet des types de données utilisés par Doctrine, nous voyons qu’ils ne correspondent pas forcément à ce que nous recherchons en terme de plage de valeurs (des INTEGER pour gérer des âges – pas signés qui plus est -, des DATETIME alors que des TIMESTAMP, deux fois moins gourmands en espace disque, suffiraient). Il y a beaucoup à redire de ce côté là sur ce schéma mais sachez qu’il est toujours possible de forcer Doctrine à utiliser des types choisis par nos soins avant de passer une migration ! Il suffit d’en faire état dans les annotations de nos entités. Attention cependant, changer le type des données choisies par Doctrine peut faire que les changements d’état de votre schéma (de la colonne modifiée, pour être plus exact) ne sont pas pris en compte comme ils devraient l’être par Doctrine, qui ne retrouve plus ses types « natifs », puisque vous les avez modifiés.

Les 10 (mauvaises) habitudes du développeur

2 réponses

Récemment il m’est venu à l’idée, dans un but ludique évidemment, de compiler quelques-uns des défauts les plus couramment rencontrés chez les développeurs. Ce n’est pas une liste exhaustive ni même une charge en règle contre les miens, mais plutôt une espèce d’introspection, d’auto-critique. En effet, quel développeur aurait la prétention de dire qu’il n’a jamais été la victime, consentante ou pas, d’ au moins un des points listés ci-dessous ?

1 – Le test…en prod !

Les fonctionnalités sont testées à la va-vite dans un coin par le développeur avant d’être parachutées sans pitié en production. Après tout, on ne teste jamais mieux qu’en condition réelle, n’est-ce pas ? Le (mauvais) développeur n’a jamais entendu parler des tests unitaires, fonctionnels ou d’intégration. Pour lui, le test est un processus visant à démontrer que tout marche à merveille, qu’il a fait du bon travail ! Non, c’est justement tout le contraire : le test est un processus AGRESSIF ! Alors évidemment, des bugs vont survenir en production et le développeur ira les corriger directement sur le serveur, à grands coups de Ctrl+S ou bien, à peine moins sale, en passant autant de fois que nécessaire des branches de hotfixes !

2 – L’appétit vorace pour la salade de technologies

Très fréquente chez les jeunes développeurs et principalement dans le milieu du développement web. On utilise des outils à la mode, sans trop chercher à connaître leur niveau de maturité, leur fréquence de mise à jour ou leur résistance à de fortes charges, une fois déployés. Tout le monde en parle et ces technos font le buzz sur des forums très fréquentés, c’est forcément qu’il y a une raison : il nous FAUT les avoir !!! Le code finit par ressembler à une grande marmite dans laquelle on aurait jeté tous les ingrédients trouvé sur les étagères de la cuisine et à terme le code va se retrouver emprisonné dans un écosystème de développement trop hétérogène et qui n’est pas sans rappeler la jungle…C’est une dérive du principe DRY (Don’t Repeat Yourself); comme tout a (presque) déjà été fait, on se contente d’agréger des outils tierce-partie sans forcément en mesurer toutes les conséquences. Ne vous rendez pas inutilement dépendants des autres : si ça existe et que c’est éprouvé, prenez ! Sinon, prenez…le temps de le faire !

3 – Le code zombie (qui ne meurt jamais vraiment)

Même lorsque certains développeurs travaillent avec des outils de gestion des versions (SVN, Git), ils conservent la mauvaise habitude de commenter des pavés de code entiers, comme s’ils voulaient garder tout ça « au cas où »…Le vieux code n’est d’aucune utilité, et encore moins si vous utilisez du version control ! Vivez et laissez mourir !

4 – Le freinage technique

Le développeur qui est réfractaire au changement constitue un frein technique. Cette fossilisation des pratiques dans des temps reculés (le cambrien ?) est pénalisante pour le reste de l’équipe. Il le sait, mais l’évolution n’est pas la première de ses préoccupations : il a souvent connu l’époque des langages procéduraux et ne voit pas bien l’intérêt de toutes ces choses « nouvelles » qui sont selon lui des lubies de programmeurs inexpérimentés (« Les objets ne sont que des containers passifs de données », « Les classes ne servent à rien », « Les contraintes d’intégrité référentielles contraignent trop le schéma des données »…). Son adage favori ?

Ça marche, alors on ne touche pas !

5 – Le nommage inconsistant des variables

Le (mauvais) développeur ne voit pas trop ce qu’on gagne à donner des identifiants « parlants » à des variables. S’il pouvait toutes les appeler « variable », il le ferait volontiers ! S’il a besoin de matérialiser une assurance, il appellera sa variable « a » : a comme assurance, enfin ! Et puis si demain les cas d’utilisation mettent en évidence la nécessité d’avoir 3 assurances et bien qu’à cela ne tienne, il créera a2 et a3 ! J’ai vu de tout personnellement; des objets nommés o, des booléens nommés b et même des variables portant le nom des personnes qui les avaient créées…les identifiants de variable doivent être courts et évocateurs !

6 – L’absence d’optimisation

Quand on écrit une requête SQL, pourquoi se préoccuper du temps qu’elle prend à s’exécuter ? Elle est syntaxiquement correcte et fait (à peu près) le job et puis ça sert à quoi les ORM ? On leur fait aveuglément confiance et tout se passera bien, ils sont faits pour ça ! De même pour le cache web, c’est géré par une couche dédiée à ça dans mon framework favori alors pourquoi devrai-je en plus m’intéresser à tout cela, j’ai déjà bien assez de travail comme ça ! Attention à ce genre de négligences quand on travaille sur des environnements à fort taux de charge ! Ne vous contentez pas de tourner la clé du véhicule et de l’utilisez, ouvrez le capot pour tirer le maximum de bénéfices de vos outils et des bonnes pratiques de développement !

7 – Le refus catégorique de la documentation

Le (mauvais) développeur pense qu’il est bon et c’est bien là le drame ! Pour lui, il suffit de lire son (excellent) code pour que tout apparaisse soudainement évident aux yeux de ses camarades codeurs qui vont avoir à reprendre son travail. La documentation c’est compliqué, il faut mettre des mots sur ce que l’on a fait, détailler, éventuellement justifier des choix…Ne négligez pas cette étape, un développeur qui ne documente pas ce qu’il fait, c’est du savoir qui va potentiellement s’évaporer !

8 – Le copier/coller comme méthode de développement

La programmation par Ctrl+C/Ctrl+V est un mal qui sévit depuis toujours…A quoi bon réfléchir, il suffit de dupliquer les choses autant de fois qu’il sera nécessaire. Et la maintenance ? Et les 10 classes à passer en revue à la moindre modification ? L’abus de Ctrl+C/Ctrl+V fait perdre 10 fois plus de temps que ce qu’il en fait gagner, mais on ne s’en rend compte souvent que des mois ou des années après; cette façon de faire est une véritable bombe à retardement, génératrice de dette technique !

9 – L’obsession de la centralisation

Le (mauvais) développeur croit comprendre que, pour limiter les modifications à tout va quand le temps du changement sera venu, il suffit simplement de tout mettre au même endroit ! Ses classes sont des monolithes de 3000 lignes qui font tout à la fois.

10 – L’euphorie de la découverte

Elle se produit lorsque le développeur trouve de nouveaux outils; quand il découvre les classes abstraites, il veut en mettre de partout, idem quand il découvre l’héritage, les fonctions statiques ou les designs patterns. Lorsque la solution est trouvée avant le problème, rien de bon ne peut en résulter. Souvenez-vous de cet adage populaire :

Quand tout ce qu’on a comme outil c’est un marteau, on a tendance à voir tous les problèmes comme des clous

On a les développements qu’on mérite !

Doctrine : les migrations avec le bundle DoctrineMigrationsBundle (2/3)

Laisser un commentaire

Maintenant que nous avons installé notre bundle dédié aux migrations des données via Doctrine, nous pouvons créer le bundle qui va servir de support à notre exercice et que nous allons appeler Scolarite car il est censé matérialiser le fonctionnement de notre université, la fabrique de développeurs ! Voici le résumé de la création de notre bundle en mode interactif :

Symfony/app/console generate:bundle
Bundle namespace: FabriqueDeDevs/ScolariteBundle
Bundle name [FabriqueDeDevsScolariteBundle]: 
Target directory [/home/sebastien.ferrandez/migrations/Symfony/src]: 
Configuration format (yml, xml, php, or annotation): yml
Do you want to generate the whole directory structure [no]? yes
You are going to generate a "FabriqueDeDevs\ScolariteBundle\FabriqueDeDevsScolariteBundle" bundle
in "/home/sebastien.ferrandez/migrations/Symfony/src/" using the "yml" format.

Generating the bundle code: OK
Checking that the bundle is autoloaded: OK
Confirm automatic update of your Kernel [yes]? 
Enabling the bundle inside the Kernel: OK
Confirm automatic update of the Routing [yes]? 
Importing the bundle routing resource: OK

Les cours à la fabrique de développeurs

Nous souhaitons modéliser de manière très simpliste la gestion des cours; des élèves s’inscrivent chez nous qui choisissent des filières composées d’un certain nombre de cours. Ces cours sont assurés par des enseignants dans des salles. Nous établissons les règles suivantes, de manière tout à fait arbitraire :

un élève appartient à une seule filière
une filière est composée d’un ou plusieurs cours
un cours n’a qu’une seule filière
un enseignant a un ou plusieurs cours
un cours n’a qu’un seul et unique enseignant mais un enseignant a un ou plusieurs cours
un cours se tient dans une seule salle à un moment donné et une salle peut abriter plusieurs cours. On peut très bien créer un cours sans salle car il arrive qu’on ne puisse décider de suite dans quelle salle il se tiendra, celle-ci sera rajoutée plus tard.

J’ai mis en gras les objets du domaine d’application qui vont donc être éligibles au titre d’entité. Nous allons commencer par les plus simples et nous allons tout générer en ligne de commande sans passer par le mode interactif :

Symfony/app/console generate:doctrine:entity --no-interaction \

--entity=FabriqueDeDevsScolariteBundle:Eleve \

--fields="nom:string(40) prenom:string(40) age:integer"

Ce que nous allons faire systématiquement c’est changer l’annotation Doctrine laissée vierge et qui contient le nom que la table cible va avoir.
Rendons nous dans le fichier nouvellement généré :

vi Symfony/src/FabriqueDeDevs/ScolariteBundle/Entity/Eleve.php

Et rajoutons la ligne en gras dans son entête:

/**
 * Eleve
 *
 * @ORM\Table(name="eleve")
 * @ORM\Entity
 */

Maintenant que nous avons généré une première entité, notre schéma de bases de données va devoir refléter ce changement, c’est à dire passer de l’état initial 0 à l’état 1 « une table élève est à créer ».
Nous faisons usage de l’argument diff :

Symfony/app/console doctrine:migrations:diff

Un fichier est généré :

Generated new migration class to "/home/sebastien.ferrandez/migrations/Symfony/app/DoctrineMigrations/Version20130420192803.php" from schema differences.

Vous devinez aisément le format de ces fichiers : VersionYYYYMMDDHHMMSS. Voyons ce que celui-ci contient :

class Version20130420192803 extends AbstractMigration
{
    public function up(Schema $schema)
    {
        // this up() migration is autogenerated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "mysql");

        $this->addSql("CREATE TABLE eleve (id INT AUTO_INCREMENT NOT NULL, nom VARCHAR(40) NOT NULL, prenom VARCHAR(40) NOT NULL, age INT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB");
    }

    public function down(Schema $schema)
    {
        // this down() migration is autogenerated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "mysql");

        $this->addSql("DROP TABLE eleve");
    }
}

Vous voyez d’emblée deux méthodes, up et down; la première est exécutée dans le sens ascendant, c’est à dire en cas de migration et l’autre dans le sens descendant, dans le cas d’une rétro-migration (d’un rollback). On retrouve dans l’un les actions antagonistes de l’autre, si dans up vous avez un create table, vous aurez un drop table dans le down.
C’est dans ce fichier que vous pouvez changer les types de données dans vos requêtes SQL avant génération des éléments de la base de données ! Quoiqu’il en soit, les changements du diff ne sont pas appliqués à la base de données tant que vous n’avez pas utilisé la commande migrate :

Symfony/app/console doctrine:migrations:migrate

Voici ce que me donne à l’écran l’exécution de cette commande :

Migrating up to 20130420192803 from 0

  ++ migrating 20130420192803

     -> CREATE TABLE eleve (id INT AUTO_INCREMENT NOT NULL, nom VARCHAR(40) NOT NULL, prenom VARCHAR(40) NOT NULL, age INT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB

  ++ migrated (0.08s)

  ------------------------

  ++ finished in 0.08
  ++ 1 migrations executed
  ++ 1 sql queries

Je migre bien de l’état 0 vers l’état 20130420192803 en faisant un CREATE TABLE eleve. Tout se passe conformément à ce que nous imaginions…Continuons avec notre deuxième entité, celle qui concerne nos enseignants :

Symfony/app/console generate:doctrine:entity --no-interaction \

--entity=FabriqueDeDevsScolariteBundle:Enseignant \

--fields="nom:string(40) prenom:string(40) age:integer"

Nous allons faire la même chose que précédemment :

donner, dans notre entité, un nom à la table qui va être créée
faire un diff
faire un migrate

Le diff produit un fichier de migration qui va cette fois concerner la table enseignant, dont nous venons de mettre le nom dans l’entité qui va la gérer. Le migrate, lui, va donner :

WARNING! You are about to execute a database migration that could result in schema changes and data lost. Are you sure you wish to continue? (y/n)y
Migrating up to 20130420214445 from 20130420192803

  ++ migrating 20130420214445

     -> CREATE TABLE enseignant (id INT AUTO_INCREMENT NOT NULL, nom VARCHAR(40) NOT NULL, prenom VARCHAR(40) NOT NULL, age INT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB

  ++ migrated (0.05s)

  ------------------------

  ++ finished in 0.05
  ++ 1 migrations executed
  ++ 1 sql queries

Nous en profitons pour voir comment évolue les tuples de table migration_versions, gérée par Doctrine :

sebastien.ferrandez@sebastien:~/migrations$ mysql -u root -p -e 'use exercice; select * from migration_versions'
Enter password: 
+----------------+
| version        |
+----------------+
| 20130420192803 |
| 20130420214445 |
+----------------+

Vous voyez que toute commande migrate entraîne la création d’une ligne dans cette table ! Nous continuons avec la création des autres entités :

Symfony/app/console generate:doctrine:entity --no-interaction \
--entity=FabriqueDeDevsScolariteBundle:Salle \
--fields="nom:string(40)"

Symfony/app/console generate:doctrine:entity --no-interaction \
--entity=FabriqueDeDevsScolariteBundle:Cours \
--fields="nom:string(40) date:datetime duree:integer"

Symfony/app/console generate:doctrine:entity --no-interaction \
--entity=FabriqueDeDevsScolariteBundle:Filiere\
--fields="nom:string(40)"

L’idée est d’isoler chaque changement du schéma de base de données (pour faire plus simple, chaque création de table) dans une migration. Si nous passons une gigantesque migration qui contient TOUT, en cas de nécessité de rétro-migrer, nous nous retrouverions à faire un grand pas en arrière au lieu de reculer à petits pas.
Nous avons fini avec les entités, nous allons à présent dans la dernière partie, « raccorder » celles qui doivent l’être ! A suivre…