Symfony 2 et PostgreSQL: Mots réservés

Symfony 2 propose une abstraction des entities très intéressante grâce à Doctrine. Je poste ce petit article car j’ai eu une erreur tout simple:

 $ php app/console doctrine:schema:update --force
Updating database schema...
 
[PDOException] SQLSTATE[42601]: Syntax error: 7 ERREUR:  erreur de syntaxe sur ou près de « User » 
LINE 1: CREATE TABLE User (id INT NOT NULL, username VARCHAR(255) NO...              
                       ^          

En fait, j’ai créé un bundle nommé User, et doctrine souhaite donc créer la table User. Le problème, c’est que user est un mot clé réservé dans PostgreSQL. Par conséquent, il faut donc forcer Doctrine à escaper le nom de la table. Pour se faire, il suffit d’ajouter une annotation Table en préfixant et suffixant le nom de la table par `.

Voici par exemple ma classe User avant la correction:

/**
 * @ORM\Entity
 */
class User extends BaseUser
{
    // ...
}

Il suffit donc de d’ajouter l’annotation @ORM\Table en spécifiant le nom de la table entouré de `. Le nouveau code est:

/**
 * @ORM\Entity
 * @ORM\Table(name="`User`")
 */
class User extends BaseUser
{
    // ...
}

Ainsi, Doctrine va générer ses requêtes en ajoutant des caractères d’échappement sur le nom de la table. Ainsi, vous n’aurez plus d’erreur! :)

Zend PHP 5.3 Developer Certified

Ça y est, je suis développeur PHP 5.3 certifié par Zend! :-)

Le principe du concours est très simple: vous avez 90 minutes pour répondre à 70 questions aléatoires concernant le fonctionnement de PHP ainsi que les différents domaines qui l’entour, à savoir le SQL, la sécurité en général, etc…

Je vous conseil de le passer, c’est sans aucun doutes un bon élément sur le CV. Si vous avez un quelconque question, n’hésitez pas!

Erreur PHP – require_once(): Unable to allocate memory for pool

Depuis peu, PHP me sort des erreurs assez bizarres, à savoir des “Unable to allocate memory for pool“. Ceci se passe notamment sur les fonctions require_once et include_once. Après quelques temps de recherche, il s’avère que c’est en fait APC qui créé cette erreur lorsqu’il n’a plus assez de place dans sa mémoire.

C’est pourquoi, pour éviter ce bug – voir ici le rapport de bug sur php.net – vous devez augmenter la mémoire allouée à APC avant d’attendre une mise à jour corrigeant ce problème.
Dans le fichier /etc/php.d/apc.ini (sous CentOS) éditez donc la ligne contenant la directive apc.shm_size en y ajoutant plusieurs mégas. Pour information, voici la configuration du serveur hébergeant D-Sites.com:

apc.shm_size=64M

Installer HipHop sur CentOS 5

HipHop pour PHP est un programme développé par Facebook permettant de compiler des applications PHP en binaire. Cela permet une augmentation très importante des performances de celle-ci. Pour l’installer sur CentOS 5, il vous suffit d’ajouter quelques dépôts et d’utiliser yum.

Note: HipHop n’est pour l’instant supporté que sur les architectures 64 bits.

Installation des nouveaux dépôts

Pour installer les 3 nouveaux dépôts, il vous suffit de lancer ces 3 commandes:

# rpm -ivh http://epel.osuosl.org/5/x86_64/epel-release-5-4.noarch.rpm
# rpm -ivh http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/x86_64/ius-release-1.0-6.ius.el5.noarch.rpm
# rpm -ivh http://pkg.tag1consulting.com/hphp/x86_64/hphp-release-1.0-2.el5.noarch.rpm

Installation de HipHop

Ensuite, il vous suffit de lancer yum pour installer HipHop via les nouveaux dépôts configurés:

# yum install hiphop-php

yum se chargera de l’installation de toutes les dépendances nécessaires et trouvées dans les dépôts.

Important: par défaut dans CentOS, la version de gcc est la version 4.1.2 alors que la version minimum pour HipHop est la version 4.4. N’oubliez pas de mettre à jour gcc, ainsi que g++.

Une fois l’installation terminée, le compileur hphp se trouve dans le /usr/bin, ainsi que dans le répertoire de HipHop, à savoir /usr/lib64/hphp/.

HipHop pour PHP, qu’est-ce que c’est ?

Le nouveau projet Open Source pour PHP du moment, c’est bien HipHop, développé pour PHP, qui consiste à transformer le code PHP en C++ puis de le compiler en utilisant g++. Présenté dans l’article précédent Facebook & PHP II: HipHop et HPHPi, voici de nouvelles informations, issues de la conférence de cette nuit.

Facebook qui utilise déjà HipHop sur 90% de ses serveurs a constaté:

  • Sur les serveurs Web: 50% de consommation CPU en moins pour un même trafic, par rapport à PHP 5.2 avec APC
  • Sur les serveurs API: 30% de consommation CPU en moins pour deux fois plus de trafic

HipHop transforme le code en C++ et le compile avec g++ mais l’utilisateur n’a pas besoin de compiler à la main son code PHP avec un outils, tout reste comme avant, avec l’édition de fichiers PHP à la volée.

Néanmoins, les fonctionnalités qui ne seront pas disponibles:

  • La fonction eval
  • La fonction create_function, qui est du même acabit que eval
  • La fonction preg_replace, avec le paramètre e, qui permet l’application de eval sur le résultat
  • De manière plus générale, l’ordre des objets ne peu pas être respecté, du fait d’une exécution non-linéaire du code. Ainsi, la fonction function_exists retourne la valeur vraie dans ce code:
    if (function_exists('foo')) {
     
        // Vrai avec HipHop
     
        // Faux avec PHP
     
    }
     
    function foo () {}
     
    ?>

En plus de HipHop, l’équipe de Facebook a développé HPHPi, c’est un interpréteur PHP, il semblerait que ça soit grâce à lui qu’il ne sera pas nécessaire de compiler le code PHP. Il fait aussi des analyses du code pour y détecter des éventuelles erreurs dues à l’utilisation de HipHop et non de PHP.

HipHop embarque son propre serveur Web et n’est pas le moment pas compatible/prêt à fonctionner avec Apache ou un autre serveur. C’est pourquoi HipHop c’est un seul processus, contrairement à PHP mais qui utilise le principe de multi-thread, plus rapide que le multi-processus car créer un processus, c’est assez long par rapport aux threads. Comme HipHop utilise sont propre Web serveur allégé, il est plus rapide et permet de mieux gérer les ressources partagées entre les threads, il permet aussi de ne pas avoir de downtime, c’est-à-dire de temps d’inaccessibilité lors d’un redémarrage de HipHop.

HipHop est pour le moment basé sur PHP 5.2, et l’équipe de chez Facebook compte bien avancer encore plus sur ce projet et voici leur Roadmap, ou liste de choses à faire:

  • Apport des fonctionnalités de PHP 5.3
  • Utilisation possible avec Apache
  • …et plus généralement la réduction de l’écart entre HipHop et PHP

Le code source qui était sensé être mis en ligne cette nuit sera maintenant mis en ligne “soon” !

Facebook & PHP II: HipHop et HPHPi

Apprenez en plus dans le nouvel article, HipHop pour PHP, qu’est-ce que c’est ?

Comme prévu et annoncé dans l’article précédent “Facebook + PHP = Hyper-PHP”, l’équipe de développement de Facebook a bien annoncer son projet de faire une sorte de compilateur pour PHP cet après-midi, vous pouvez la retrouver en anglais à cette adresse.

Ce n’est en fait pas sous le nom de Hyper-PHP que les développeurs de Facebook ont décider de sortir leur moteur, mais sous le nom de HipHop, accompagné de HPHPi.

Facebook n’a en réalité pas tout à fait réécrit PHP depuis le début, mais a décidé de créer une extension PHP qui transforme un code PHP en un code C++, puis qui le compile. HipHop, c’est le nom du module/programme/de l’extention PHP qui va transformer votre code PHP en code C++, puis le compiler en utilisant le traditionnel g++. HPHPi, lui, permet de ne pas avoir à mettre en place un système de compilation en plus, et d’avoir simplement a utiliser PHP comme avant, mais en beaucoup plus rapide.

Les chiffres ont néanmoins changer car on ne parle ici que d’une diminution de 50%contre 80% d’après les rumeurs précédentesde la consommation du CPU, sans même avancer de chiffres d’augmentation de performances, même si il est tout de même le sujet de tout l’article de Facebook, c’est donc sans douter que ça a très certainement un gros bénéfice, puisque Facebook.com l’utilise déjà sur près de 90% de ses serveurs!

À noter tout de même que dans l’article, il est précisé que des fonctions sont perdues, comme la fonction eval par exemple (ce n’est pas plus mal pour celle-ci) et que l’équipe de développement a réécrit de nombreuses extensions pour les adapter à leur HipHop PHP, ce qui fera sans aucun doute que cette innovation pour PHP ne sera pas ajoutée à PHP, contrairement aux caches OPCodes qui le seront pour PHP 6, et restera un projet distant externe à PHP pour un petit moment.

C’est donc à tester sans attendre, lorsque que les sources seront disponibles dans la nuit (fin d’après-midi chez nos amis américains) à cette adresse, qui ne marchera que lorsque les sources seront disponibles:

Dès possible je ferais des tests et des benchmarks, que je ne manquerait pas de diffuser ici.

Facebook + PHP = Hyper-PHP

Lisez l’article plus récent: PHP & Facebook II: HipHop et HPHPi »

Voilà quelques temps que les rumeurs circulent, je vais donc faire un petit résumé de ce que l’on appelle Hyper-PHP, ou HPHP. Le site web de l’entreprise Facebook est composé à 90% de PHP, un langage de programmation tourné vers le Web, qui est ré-analysé depuis de début à chaque fois, c’est-à-dire qu’a chaque installation, le runtime PHP doit analyser toute la source pour faire tourner le script PHP, c’est ce qui lui confère une lenteur par rapport aux applications compilées.

Et bien Facebook aurait décidé, il y a 2 ans, de mettre un développeur à part entière sur ce projet, qui aurait pour but de créer une sorte de compilateur pour PHP. C’est en effet ce que ressort d’une interview anonyme recueilli par TheRumpus.net.

He is creating HPHP, Hyper-PHP, which means he’s literally rewriting the entire language. […] So this engineer is converting the site from one that runs on a scripted language to one that runs on a compiled language.

Alors que l’annonce doit avoir lieu aujourd’hui, le 2 février 2010, cette nouvelle mouture de PHP, si l’on peux l’appeler comme ça, va très certainement changer beaucoup de choses car d’après l’ingénieur Facebook chargé de ce projet, Hyper-PHP consommerait 80% de CPU en moins tout en ayant des performances augmentées de 80% ! Il sera de plus partagé en Open Source, comme un grand nombre de projets de Facebook.

A bientôt pour la suite! :-)

Gettext: Utiliser plusieurs fichiers de traduction en même temps

Dans certains projets modulaires, certains modules utilisent l’internationalisation (avec gettext notamment). Le problème, c’est quand il y en a plusieurs, quel fichier gettext va-t-il être utilisé ? C’est assez difficile à répondre car gettext est très…très pauvre en fonctions de débugguage. En réalité c’est impossible de débugguer gettext sans procéder par tests.

Du coup, ça serait très pratique d’utiliser plusieurs fichiers compilés de langue. Pour ça, il y a la fonction ngettext qui permet de spécifier le nom du domaine à utiliser. Le nom du domaine c’est le premier paramètre de bindtextdomain qui vous avez dû appeler pour initialiser le fichier de texte à trouver dedans.

C’est très pratique, surtout, lisez la documentation de ngettext pour pouvoir utiliser plusieurs fichiers de traduction dans un même programme PHP !

PHPpgAdmin 4.2.2 et PHP 5.3

Depuis PHP 5.3 toutes les fonctions utilisant les regex POSIX (ereg* et split*) sont maintenant obsolètes (qualifiée de DEPRECATED dans la documentation) et vont être supprimées dans PHP 6. Ces fonctions étant moins performantes, devenues presque inutiles à tous les projets cherchant la performance et surtout alourdissant PHP dans le sens où il y avait deux choix possible de regex, il était normal qu’elle disparaissent.

Néanmoins, il faut savoir que c’est la méthode la plus ancienne et donc la plus utilisée dans les portions de codes les plus vielles. Il se trouve que dans la version 4.2.2 de phpPgAdmin (dernière version stable, sortie il y a 1 an à deux jours près ;-) ) il y a encore ces fonctions à quelques endroits, provoquant des Warning lors de l’éxécution de phpPgAdmin sous PHP 5.3.

Pour supprimer ces erreurs, voici un patch dans lequel j’ai remplacer toutes les occurrences de ereg* et split* par les équivalents en regex PCRE:

$ cd phppgadmin-4.3.3
$ wget http://www.d-sites.com/wp-content/uploads/2009/12/phppgadmin4.2.2-php5.3.patch
$ patch -p0 < phppgadmin4.2.2-php5.3.patch

Cannot represent a stream of type SSH2 Channel as a select()able descriptor

Une extension PHP nommé ssh2, que l’on peut retrouver dans le dépôt pecl permet de se connecter à un serveur SSH depuis un script PHP à l’aide de plusieurs fonctions. Plus particulièrement, la fonction ssh2_shell qui retourne un flux de données, ou stream, nous permet de mettre en place entre le script PHP et le serveur SSH un vrai échange complet. L’intérêt d’avoir un flux de données pour converser avec un serveur SSH est que l’on peut manipuler assez facilement à l’aide de toutes les fonctions stream_* ces flux. Ça, c’est la théorie.

En pratique, il s’avère que l’utilisation d’un flux SSH2 Channel (retourné par ssh2_shell) avec la fonction stream_select qui permet d’attendre que le flux “change” – c’est-à-dire qu’une donnée arrive – est impossible. En effet, pour utiliser le flux avec stream_select, il faut pouvoir transformer ce flux en une donnée utilisable par la fonction C select(). C’est ce que l’on appelle “caster un stream” en franglais et “to cast a stream” en anglais. Le problème, c’est que la librairie pecl/ssh2 (basée sur libssh2) n’implémente pas cette fonctionnalité, ce qui nous donne droit à un magnifique:

Warning: stream_select() [function.stream-select]: cannot represent a stream of type SSH2 Channel as a select()able descriptor in /path/to/file.php on line XX

Nous allons donc voir comment ajouter cette fonctionnalité simplement, à l’aide de patchs développés par mes soins. Continue reading