Je me pose une petite question à propos les fonctions mysqli_* associées à
MySQL4.1 quand on a des scripts utilisant les fonction mysql_*.
Je m'explique avec un exemple bateau :
<?php
/* - On met ça dans un fichier - */
function mysql_connect($host,$user,$pass) {
return mysqli_connect($host,$user,$pass);
}
function mysql_select_db($db,$cnx) {
return mysqli_select_db($cnx,$db);
}
function mysql_query($sql,$cnx) {
return mysqli_query($cnx,$sql);
}
function mysql_fetch_array($result) {
return mysqli_fetch_array($result);
}
function mysql_free_result($result) {
mysqli_free_result($result);
}
/* ----------------------------- */
// Un script type
// ---------------
$cnx = mysql_connect("localhost", "user", "pass") or
die("Impossible de se connecter : " . mysql_error());
mysql_select_db("test",$cnx);
$result = mysql_query("SELECT id, name FROM toto",$cnx);
while ($row = mysql_fetch_array($result)) {
echo "<p>$row[id] => $row[name]</p>";
}
mysql_free_result($result);
?>
Bien que cela fonctionne (je viens de tester), ce genre de chose est elle
envisageable si on migre le mysql4.0 vers un mysql4.1 sur un serveur et si
non, pourquoi ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
loufoque
Laurent Seguin a dit le 07/11/2004 14:02:
Bien que cela fonctionne (je viens de tester), ce genre de chose est elle envisageable si on migre le mysql4.0 vers un mysql4.1 sur un serveur et si non, pourquoi ?
C'est envisageable, oui. Après, est-ce que ça change vraiment les performances ?
Laurent Seguin a dit le 07/11/2004 14:02:
Bien que cela fonctionne (je viens de tester), ce genre de chose est elle
envisageable si on migre le mysql4.0 vers un mysql4.1 sur un serveur et si
non, pourquoi ?
C'est envisageable, oui.
Après, est-ce que ça change vraiment les performances ?
Bien que cela fonctionne (je viens de tester), ce genre de chose est elle envisageable si on migre le mysql4.0 vers un mysql4.1 sur un serveur et si non, pourquoi ?
C'est envisageable, oui. Après, est-ce que ça change vraiment les performances ?
marc.quinton-PAS-DE-
Bien que cela fonctionne (je viens de tester), ce genre de chose est elle envisageable si on migre le mysql4.0 vers un mysql4.1 sur un serveur et si non, pourquoi ?
non :
<b>Fatal error</b>: Cannot redeclare mysql_connect() in ...
tu ne peux redéclarer cette fonction. Mais peut-etre qu'il existe des mécanismes d'effacement de fonction suivi d'une redéclaration.
Bien que cela fonctionne (je viens de tester), ce genre de chose est elle
envisageable si on migre le mysql4.0 vers un mysql4.1 sur un serveur et si
non, pourquoi ?
non :
<b>Fatal error</b>: Cannot redeclare mysql_connect() in ...
tu ne peux redéclarer cette fonction. Mais peut-etre qu'il existe
des mécanismes d'effacement de fonction suivi d'une redéclaration.
Bien que cela fonctionne (je viens de tester), ce genre de chose est elle envisageable si on migre le mysql4.0 vers un mysql4.1 sur un serveur et si non, pourquoi ?
non :
<b>Fatal error</b>: Cannot redeclare mysql_connect() in ...
tu ne peux redéclarer cette fonction. Mais peut-etre qu'il existe des mécanismes d'effacement de fonction suivi d'une redéclaration.
loufoque
a dit le 08/11/2004 :
non :
<b>Fatal error</b>: Cannot redeclare mysql_connect() in ...
tu ne peux redéclarer cette fonction. Mais peut-etre qu'il existe des mécanismes d'effacement de fonction suivi d'une redéclaration.
En fait j'avais cru comprendre qu'il voulait enlever MySQL pour mettre MySQLi à la place (comme le laisse entendre le titre de son message, "MySQL -> MySQLi". Donc si la bibliothèque MySQL n'est plus chargée, il ne devrait plus y avoir de problèmes.
marc.quinton-PAS-DE-@-SPAM-aviation-civile.gouv.fr a dit le 08/11/2004 :
non :
<b>Fatal error</b>: Cannot redeclare mysql_connect() in ...
tu ne peux redéclarer cette fonction. Mais peut-etre qu'il existe
des mécanismes d'effacement de fonction suivi d'une redéclaration.
En fait j'avais cru comprendre qu'il voulait enlever MySQL pour mettre
MySQLi à la place (comme le laisse entendre le titre de son message,
"MySQL -> MySQLi".
Donc si la bibliothèque MySQL n'est plus chargée, il ne devrait plus y
avoir de problèmes.
<b>Fatal error</b>: Cannot redeclare mysql_connect() in ...
tu ne peux redéclarer cette fonction. Mais peut-etre qu'il existe des mécanismes d'effacement de fonction suivi d'une redéclaration.
En fait j'avais cru comprendre qu'il voulait enlever MySQL pour mettre MySQLi à la place (comme le laisse entendre le titre de son message, "MySQL -> MySQLi". Donc si la bibliothèque MySQL n'est plus chargée, il ne devrait plus y avoir de problèmes.
marc.quinton-PAS-DE-
<b>Fatal error</b>: Cannot redeclare mysql_connect() in ...
tu ne peux redéclarer cette fonction. Mais peut-etre qu'il existe des mécanismes d'effacement de fonction suivi d'une redéclaration.
loufoque , le 08 nov. 2004 13:13:36, écrivait ceci:
<b>Fatal error</b>: Cannot redeclare mysql_connect() in ...
tu ne peux redéclarer cette fonction. Mais peut-etre qu'il existe des mécanismes d'effacement de fonction suivi d'une redéclaration.
En fait j'avais cru comprendre qu'il voulait enlever MySQL pour mettre MySQLi à la place (comme le laisse entendre le titre de son message, "MySQL -> MySQLi". Donc si la bibliothèque MySQL n'est plus chargée, il ne devrait plus y avoir de problèmes.
Toutafé ! Surtout quand je dis : ça fonctionne (je viens de tester) C'est que j'ai *vraiment* testé. :-)
loufoque <mat.wilmots.remove@nospam.wanadoo.fr>, le 08 nov. 2004 13:13:36,
écrivait ceci:
<b>Fatal error</b>: Cannot redeclare mysql_connect() in ...
tu ne peux redéclarer cette fonction. Mais peut-etre qu'il existe
des mécanismes d'effacement de fonction suivi d'une redéclaration.
En fait j'avais cru comprendre qu'il voulait enlever MySQL pour mettre
MySQLi à la place (comme le laisse entendre le titre de son message,
"MySQL -> MySQLi".
Donc si la bibliothèque MySQL n'est plus chargée, il ne devrait plus y
avoir de problèmes.
Toutafé !
Surtout quand je dis : ça fonctionne (je viens de tester)
C'est que j'ai *vraiment* testé. :-)
loufoque , le 08 nov. 2004 13:13:36, écrivait ceci:
<b>Fatal error</b>: Cannot redeclare mysql_connect() in ...
tu ne peux redéclarer cette fonction. Mais peut-etre qu'il existe des mécanismes d'effacement de fonction suivi d'une redéclaration.
En fait j'avais cru comprendre qu'il voulait enlever MySQL pour mettre MySQLi à la place (comme le laisse entendre le titre de son message, "MySQL -> MySQLi". Donc si la bibliothèque MySQL n'est plus chargée, il ne devrait plus y avoir de problèmes.
Toutafé ! Surtout quand je dis : ça fonctionne (je viens de tester) C'est que j'ai *vraiment* testé. :-)
John GALLET
Salut Laurent,
Bien que cela fonctionne (je viens de tester), ce genre de chose est elle envisageable si on migre le mysql4.0 vers un mysql4.1 sur un serveur et si non, pourquoi ?
Tu peux effectivement faire ce genre de choses mais si tu as besoin, pour une raison quelconque, de faire cohabiter les deux ensembles de fonctions, il me sembe qu'un bon vieux find avec un sed sera aussi efficace. Genre : find . -name "*.php" -exec sed 's/mysql_/mysqli_/' {} ;
à la racine une COPIE de ton arborescence, suivit d'un diff -r pour voir les différences, devrait le faire sans trop de mal.
Attention, non testé ;-)
Si c'est trop violent, tu peux faire autant de sed successifs que de fonctions.
Pour moi c'est plus un problème de portabilité entre plateformes qu'autre chose.
a++; John
Salut Laurent,
Bien que cela fonctionne (je viens de tester), ce genre de chose est elle
envisageable si on migre le mysql4.0 vers un mysql4.1 sur un serveur et si
non, pourquoi ?
Tu peux effectivement faire ce genre de choses mais si tu as besoin, pour
une raison quelconque, de faire cohabiter les deux ensembles de fonctions,
il me sembe qu'un bon vieux find avec un sed sera aussi efficace.
Genre :
find . -name "*.php" -exec sed 's/mysql_/mysqli_/' {} ;
à la racine une COPIE de ton arborescence, suivit d'un diff -r pour voir
les différences, devrait le faire sans trop de mal.
Attention, non testé ;-)
Si c'est trop violent, tu peux faire autant de sed successifs que de
fonctions.
Pour moi c'est plus un problème de portabilité entre plateformes qu'autre
chose.
Bien que cela fonctionne (je viens de tester), ce genre de chose est elle envisageable si on migre le mysql4.0 vers un mysql4.1 sur un serveur et si non, pourquoi ?
Tu peux effectivement faire ce genre de choses mais si tu as besoin, pour une raison quelconque, de faire cohabiter les deux ensembles de fonctions, il me sembe qu'un bon vieux find avec un sed sera aussi efficace. Genre : find . -name "*.php" -exec sed 's/mysql_/mysqli_/' {} ;
à la racine une COPIE de ton arborescence, suivit d'un diff -r pour voir les différences, devrait le faire sans trop de mal.
Attention, non testé ;-)
Si c'est trop violent, tu peux faire autant de sed successifs que de fonctions.
Pour moi c'est plus un problème de portabilité entre plateformes qu'autre chose.
