PHPUnit: MySQL “Too many connections” error

Even if it's the best idea to write tests that need a real database connection, sometimes it's something needed. If you're using Symfony2, you can simply follow the "How to test Doctrine Repositories" part of Symfony documentation to do that.

But if you're running a large amount of tests you'll get the following MySQL error:

SQLSTATE[08004] [1040] Too many connections

This means that you reached the maximum number of simultanous connections (max_connections parameter in my.cnf). To fix that behaviour, I had to change the processIsolation parameter of PHPUnit in the phpunit.xml file, like this:

<phpunit
backupGlobals = "false"
backupStaticAttributes = "false"
colors = "true"
convertErrorsToExceptions = "true"
convertNoticesToExceptions = "true"
convertWarningsToExceptions = "true"
processIsolation = "true"
stopOnFailure = "false"
syntaxCheck = "false"
bootstrap = "bootstrap.php.cache" >

facebooktwittergoogle_plusredditpinterestlinkedinmail

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:

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:

Il suffit donc de d'ajouter l'annotation @ORMTable en spécifiant le nom de la table entouré de . Le nouveau code est:

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

facebooktwittergoogle_plusredditpinterestlinkedinmail

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 PostgreSQL: Deux opérateurs pour les varchar arrays

facebooktwittergoogle_plusredditpinterestlinkedinmail

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:

facebooktwittergoogle_plusredditpinterestlinkedinmail

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:

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 PostgreSQL: Utiliser le principe du type “varlena”

facebooktwittergoogle_plusredditpinterestlinkedinmail

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 Librairie parse_url version 1.1

facebooktwittergoogle_plusredditpinterestlinkedinmail

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 Analyser des adresses URL avec parse_url dans PostgreSQL

facebooktwittergoogle_plusredditpinterestlinkedinmail

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 PHP PDO: Récupérer les notes du serveur de bases de données

facebooktwittergoogle_plusredditpinterestlinkedinmail

Pl/PgSQL: Parcourir un tableau

Pour PostgreSQL >= 9.1

Depuis PostgreSQL 9.1, nous pouvons utiliser l’opérateur FOREACH, comme ceci:

Pour PostgreSQL > 8.3 et <= 9.0

Pour parcourir un tableau de données, ça pourrait être très simple en utilisant FOR ... IN ... mais cette synthaxe utilise uniquement des données de type RECORD pour fonctionner. C’est pourquoi, depuis PostgreSQL 8.4, il y a une fonction unnest qui permet de transformer un tableau (array) en un RECORD. Avant, nous allons créer cette fonction.

Dans votre bloc Pl/PgSQL, faites comme ceci:

Données:

  • v_monarray est un tableau de données (exemple: integer[] )
  • v_array_data est une variable contenant la valeur de la donnée du tableau du tour (exemple: integer)
    Note: Doit être du même type que la donnée du tableau

Pour PostgreSQL <= 8.3

Pour ces versions, nous allons créer la fonction unnset (voir article sur le wiki de PostgreSQL) comme ceci:

Ainsi, vous pouvez appliquer l’exemple pour PostgreSQL 8.4.

Sinon, vous pouvez aussi utiliser WHILE comme ceci:

Avec:

  • v_array_count la taille du tableau
  • v_loop_i une variable de type integer initialisée à 1
facebooktwittergoogle_plusredditpinterestlinkedinmail