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! :)

Monitoring PostgreSQL avec Zabbix

Avant tout, il faut installer ZTC (Zabbix Template Collection), qui contient un grand nombre de templates (côté agent) Zabbix qui récupèrent des données sur différentes applications, comme Apache, Nginx, MySQL, PostgreSQL, Slony, …

Note: si vous n’avez pas installé Zabbix, vous pouvez lire le guide sur comment installer Zabbix 1.8 avec PostgreSQL sur CentOS 5.

Installation de ZTC

Vous pouvez télécharger les sources ou des paquets (pour le moment uniquement RPM) dans le gestionnaire de dépôt de ZTC. Nous allons ici installer la dernière version en date, la 10.11:

$ wget https://bitbucket.org/rvs/ztc/downloads/ztc-10.11-1.noarch.rpm
# rpm -Uvh ztc-10.11-1.noarch.rpm

Voilà, ZTC est installé et a créé des fichiers de configuration pour les différentes applications dans le dossier /etc/zabbix-agent.d. Par défaut, tous les fichiers sont dans ce dossier. Ce que je vous propose, c’est de ne pas tous les activer sur l’agent, car cela risquerait de le charger inutilement. C’est pourquoi, on nous créer deux dossiers: enabled et available qui contiendrons les fichiers de configuration, un peu comme les configurations de modules Apache.

# mkdir /etc/zabbix-agent.d/{available,enabled}
# mv /etc/zabbix-agent.d/*.conf /etc/zabbix-agent.d/available

Nous allons également configurer l’agent Zabbix pour charger les fichiers de configuration activés: dans le fichier /etc/zabbix/zabbix_agentd.conf, ajoutez cette ligne:

Include=/etc/zabbix-agent.d/enabled/

Continue reading

Installer Zabbix 1.8.x avec PostgreSQL sur CentOS 5

Zabbix est une application de monitoring. Elle permet de surveiller votre parc de serveurs, d’applications et de sites Web. Elle se compose d’un serveur ainsi que d’agents (facultatifs, mais qui permettent de récupérer plus d’informations locales que SNMP) sur chacune des machines à monitorer.

Nous allons voir comment installer le serveur Zabbix ainsi que son front-end Web écrit en PHP, sous CentOS 5.

Installation du serveur Zabbix

Installation des dépendances

Avant tout, nous allons installer les dépendances de Zabbix, à savoir les librairies zlib, curl, openssl, net-snmp et openIPMI, pour pouvoir utiliser au maximum les fonctionnalités de Zabbix. Nous allons également installer un système de gestion de base de données, pour stocker toutes les données: PostgreSQL.

# yum install zlib-devel glibc-devel curl-devel gcc automake libidn-devel openssl-devel net-snmp-devel rpm-devel OpenIPMI-devel postgresql84-devel

Nous allons maintenant initialiser la nouvelle base de données PostgreSQL:

# /etc/init.d/postgresql initdb

Important: si vous avez déjà une base de données PostgreSQL sur votre serveur, n’initialisez pas la base! Vous pouvez également voir comment installer PostgreSQL 8.x sous Debian.

Installation du serveur

Maintenant, nous allons télécharger les sources de Zabbix pour l’installer. Vous trouverez les archives des sources sur la page de téléchargement du site Web de Zabbix.

$ wget http://sourceforge.net/projects/zabbix/files/ZABBIX%20Latest%20Stable/1.8.4/zabbix-1.8.4.tar.gz/download -O zabbix.tar.gz
$ tar -xzf zabbix.tar.gz
$ cd zabbix-*

Maintenant, nous allons commencer le processus de compilation en utilisant le programme ./configure avec nos options:

$ ./configure --enable-server --with-pgsql --with-net-snmp --with-libcurl --with-openipmi --enable-agent --enable-ipv6

Si toutes les dépendances sont satisfaites, vous devriez avoir ce message:

Enable server: yes
Server details:
With database: PostgreSQL
WEB Monitoring via: cURL
Native Jabber: no
SNMP: net-snmp
IPMI: openipmi
SSH: no

[...]
Enable agent: yes
Agent details:
Linker flags: -rdynamic
Libraries: -lm -lresolv

LDAP support: no
IPv6 support: yes

Ensuite, il nous reste à compiler Zabbix:

# make

À ce moment, vous pouvez installer Zabbix sur votre système comme ceci:

# make install

Note: Vous pouvez également créer un paquet de Zabbix avec cette configuration grâce au programme checkinstall.

Continue reading

PostgreSQL: Deux opérateurs pour les varchar arrays

PostgreSQL contient un module non activé par défaut nommé "intarray". Celui-ci permet d’ajouter des opérateurs et des fonctions entre tableaux d’entiers ou entre tableaux et entiers. les deux principales fonctionnalités sont, pour moi, les deux opérateurs + et - entre les tableaux d’entiers, int[].

Ayant pris l’habitude de les utiliser pour une application, j’ai eu besoin de ces mêmes opérateurs + et - pour des tableaux de chaines de caractères, varchar[]. C’est pourquoi, j’ai créé deux fonctions en Pl/pgSQL liées à ces deux opérateurs, afin de pouvoir faire la même chose qu’avec intarray. Concrètement, après la création de ces fonctions et de ces opérateurs, vous pouvez faire:

Continue reading

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

PostgreSQL: parse_url v2

La version 2 de la librairie parse_url pour PostgreSQL, permettant de gérer des adresses URL au seins de la base de données est sortie. Elle permet de créer des tables avec des champs de type url afin d’être plus rapide lors de la sélection de certaines parties de l’URL.

Accéder à la page de parse_url v2 »

PostgreSQL: Utiliser le principe du type “varlena”

PostgreSQL utilise depuis Postgres le type varlena, qui signifie variable length array en anglais, soit tableau à taille variable en français. Ce type permet de stocker des données à taille variable dans la base de données. Le principe est très simple: stocker en mémoire une ou plusieurs données de façon contiguë. De plus, il ne doit pas y avoir de pointeur dans le type.

La structure “de base” de varlena est définie dans le fichier src/include/c.h, line 401 pour PostgreSQL 8.4 par:

struct varlena
{
	char	vl_len_[4];
	char	vl_dat[1];
};

Note: le premier tableau de 4 caractères peu très bien est remplacé par un int32, ça revient au même: 4 octets.

Ce type représente le principe: un champ vl_dat, qui contiendra la donnée et d’autres champs qui ne doivent pas être des pointeurs, mais des entiers le plus souvent (ici un tableau de 4 caractères), qui contiennent des informations sur cette donnée. Cela permet à PostgreSQL de pouvoir stocker sur le disque et en mémoire toutes les données en une fois, pouvant ainsi les déplacer comme bon lui semble.

Attention: la propriété qui contient les données doit être la dernière propriété de la structure.

Tout type de donnée un peu complexe doit utiliser ce principe lorsqu’il stocke des données de taille variable en base afin d’assurer une intégrité aux données stockées. Nous allons voir, à l’aide de la librairie parse_url pour PostgreSQL, comment créer un type de données stockant de nombreuses données de taille variable dans une seule et même donnée, dans le but d’être utilisé comme type de colonne dans une table par exemple.

Continue reading

Librairie parse_url version 1.1

Présentée précédement pour ça première version, voici la version 1.1 de la librairie parse_url pour PostgreSQL. Cette nouvelle version corrige:

Elle ajoute:

  • Des clés de récupération via parse_url(text, text) :
    • host+port qui retourne l’hostname et le numéro du port, avec un “:” entre les deux
    • path+query qui retourne le path et le champ “query” avec un “?” entre les deux

Note: voir la page du projet

Continue reading

Analyser des adresses URL avec parse_url dans PostgreSQL

Note: La version 1.1 est sortie.

Note: voir la page du projet

Si vous stockez des adresses URL dans votre base de données, il est possible que vous souhaitiez récupérer des données de celles-ci comme le nom de domaine, le path qui correspond à /dossier/fichier.html par exemple, les paramètres envoyés, etc… Pour ça, il fallait auparavant utiliser par exemple une fonction Pl/Sh pour demander à un script PHP tel ou tel champ de l’URL, analysée avec la fonction parse_url de PHP.

Maintenant, il en est tout autrement ! ;-) Basée sur la fonction parse_url de PHP, j’ai codé une simple petite fonction parse_url utilisable à partir de PostgreSQL 8.4. Dans ce module “parse_url”, il y a:

  • Une fonction parse_url (text) qui retourne un record. Elle prend pour argument une adresse URL sous une forme texte et retourne un record nommé “url_record” défini par ("scheme" text, "user" text, "pass" text, "host" text, "port" integer, "path" text, "query" text, "fragment" text)
  • Une fonction parse_url (text, text) qui retourne une valeur texte correspondant au champ nommé dans le second argument. Le champ peut être:
    • scheme: Le schéma de l’adresse URL. (http, https, ftp…)
    • user: Le nom d’utilisateur si fourni
    • pass: Le mot de passe si fourni
    • host: Le nom de domaine
    • port: Le port de connexion si spécifié
    • path: L’adresse du fichier par rapport au nom de domaine
    • query: Les paramètres URL envoyés
    • fragment: Le contenu situé après “#”

Continue reading

PHP PDO: Récupérer les notes du serveur de bases de données

Certaines bases de données comme Oracle et PostgreSQL – MySQL le fait partiellement – renvoient des notes (notices en anglais) concernant une requête ALTER, UPDATE ou DELETE. Il est même possible de renvoyer des notes sous PostgreSQL et Oracle en faisant respectivement RAISE NOTICE et DMBS_OUTPUT.PUT_LINE. Ces informations peuvent parfois être retournée depuis les drivers de base de la base de données mais pas avec PDO.

Note: Ces patchs sont créés et testés pour PHP 5.3 uniquement.

Accèder à la page du projet PDO – Notices

Continue reading