juin
2009
Un article de doctorrock
Si vous utilisez encore ext/mysql (les fonctions PHP mysql_*) , soit vous êtes sous PHP4 (vous connaissez donc la solution : PHP5), soit vous êtes sous PHP5, mais supportez une vieille application.
Je rappelle – et Zend vient de fermer le ticket #ZF-5406 confirmant ceci – :
L’extension ext/mysql pour MySQL est vielle, elle est maintenue mais n’est plus développée (enrichie), elle concerne MySQL < 4.1.3. Elle ne fournit pas d’API concernant le traitement des procédures stockées, des transactions, des requêtes préparées. De plus, cette extension ne fournit que des fonctions et aucuns objets, ce qui la rend d’autant moins facilement utilisable.
Citation du manuel PHP :
Qu’est-ce que l’extension mysql de PHP?
C’est l’extension originelle, conçue pour réaliser des applications PHP qui sont en interaction avec une base MySQL. L’extension mysql fournit une interface procédurale, et est destinée à une utilisation avec les serveurs MySQL versions 4.1.3 et plus anciennes. Cette extension peut être utilisée avec les versions de MySQL 4.1.3 et plus récente, mais elle ne pourra pas tirer partie des nouvelles fonctionnalités.
Note: Si vous utilisez MySQL versions 4.1.3 ou plus récent, il est fortement recommandé d’utiliser l’extension mysqli.
Toute nouvelle application devrait utiliser ext/mysqli ou ext/pdo.
La question de la migration d’un existant est épineuse en fonction de l’application, mais si une refonte doit s’annoncer, elle doit commencer par là.
Toute application « moderne » tirera bien des avantages de ext/mysqli ou encore ext/pdo_mysql. Quant à la question de la version de MySQL, aujourd’hui il y a quand même beaucoup de 5.x , même si on trouve encore des 4.x ou 3.x. Même sur ces vieilles versions, ext/mysqli tourne (mais les nouvelles fonctions non prises en charge par MySQL renverront une erreur).
Pour les allergiques à l’objet, ext/mysqli propose une interface entièrement procédurale (et une objet aussi) 
De plus, la migration n’est pas très difficile, les API se ressemblant énormément. Voyez plutôt ma présentation à SolutionsLinux
3 Commentaires + Ajouter un commentaire
Commentaires récents
Archives
- novembre 2010
- août 2010
- juillet 2010
- juin 2010
- mai 2010
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009
- décembre 2008
- novembre 2008
- octobre 2008
- septembre 2008
- août 2008
- juillet 2008
- juin 2008
- mai 2008
- avril 2008
- mars 2008
- février 2008
- janvier 2008
- décembre 2007
- novembre 2007
- octobre 2007
- septembre 2007
- août 2007
- juillet 2007
- juin 2007
- mai 2007
- avril 2007
- mars 2007
- février 2007
A tout hasard je viens de retrouver le logiciel en question: PKGI, création rapide d’environnements applicatifs indépendants sous Debian
http://linuxfr.org/2009/06/02/25545.html
Tu veux faire cohabiter des versions différentes sur un même serveur Virtuel | Physique ?
Dans tous les cas à part en venir à avoir un vaste de bordel et des conflits de tel ou tel librairie au niveau du système…. bof…
Après peut être avec un système de « chroot » ou autre y’a surement moyen d’avoir un truc pas trop bordélique..
J’avais vue y’a quelques temps une news sur LinuxFr je crois qui parler d’un moyen de gérer ce genre d’environnement différent… à retrouver…
Si c’est un serveur physique, rajoute un système de virtualisation…
_Gabriel_ tu t’emballes un peu vite peut être, Julien précise quand même « Toute nouvelle application devrait utiliser ext/mysqli ou ext/pdo. »
Effectivement tu ne peux pas balancer tout l’existant et tout refaire. Mais il est allucinant de voir le nombre de gens qui utilisent des méthodes dépassées pour des nouveaux projets !
« la modernité d’une application ne tient sûrement pas à la version des librairies utilisées » non mais ça aide ! Quand tu utilise des extensions bien faite, optimisé, c’est quand même largement mieux que de coder ce dont t’as besoin dans le langage final (PHP ici).
Bonjour,
Où est le problème a encore utiliser ext/mysql ? Où est le problème a encore utiliser php 4 ? Je comprends vraiment peu ce besoin de s’émerveiller sur la dernier version de ceci ou de cela ! C’est sûrement peut-être que toutes ces bonnes âmes sont peu en contact avec la réalité du métier. Moi, j’ai des clients qui ont des application en php3, php4, mysql3, mysql4, qui ont investi pour leur application, qui du reste fonctionne bien et en sont pleinement satisfait. Allez leur dire qu’il faut refondre pour faire maintenant du php5/mysql5, qu’ils n’en tireront aucun bénéfice visible sauf la joie de faire « moderne » … d’ailleurs à ce sujet, la modernité d’une application ne tient sûrement pas à la version des librairies utilisées ! Ca se saurait ! Et en parlant encore de modernité, ca serait bien que les blogs gravitant autour du sujet se modernise un peu car l’ensemble des sujets sent un peu trop le réchauffé … Je vois vraiment peu de monde s’épancher sur de la SOA en php, sur l’aop en php (par exemple) et en ouvrant quotidiennement planete-php.fr/, franchement le niveau vole pas bien haut (sauf très plaisantes exceptions). Je sais la première remarque qui viendra à l’esprit au sujet de mon message sera « ouais mais toi qu’est-ce t’as fait au lieu de critiquer ». Ben moi, je fais ce que j’ai à faire mais au moins je ne viens pas brasser de l’air sur un blog … C’est déjà çà de pris.
Notre à l’auteur: ne pas prendre ma réponse personnellement mais comme une réponse globale à un certaine dérive que je constate trop souvent. Ce billet est juste une occasion de l’ouvrir. Je suis entièrement d’accord avec le fond mais la forme … D’ailleurs au lieu de faire des billets sur « c’est pas top, faut migrer vieux », ca serait intéressant d’avoir des retours sur comment faire cohabiter x version de php, x version de mysql sur un serveur … par exemple !
Cordialement,