Pour PostgreSql (je connais un peu mais je n'aime pas), il y a:
mysql_num_fields() => pg_num_fields()
mysql_list_fields() => Je n'ai pas trouvé de correspondance mais peut-être est-il possible de "construire" la fonction ?

Pour MySqli, je ne connais pas du tout mais j'ai tout de même trouvé çà:
mysql_num_fields() => sqlite_num_fields()
mysql_list_fields() => Une requête sqlite : PRAGMA table_info('nomtable') retourne la liste des champs de la table en question.


Ces fonctions peuvent être très utiles pour les développeurs de plugins. Il peut arriver (et c'est mon cas) qu'une mise à jour nécessite de connaitre le nombre de champs ou la liste des champs d'une table (config par exemple).

@Nicolas: Etant à l'origine du portage de Piwigo sur d'autres bases de données, qu'en penses-tu?

nicolas a écrit:

Eric a écrit:

Quid de mysql_list_fields() et mysql_num_fields() ?
Je ne trouve pas leur correspondance pwg_db_###() dans functions_mysql.inc.php. Un oubli ? Une volonté ?

Avant de rajouter quoi que ce soit, j'aimerais comprendre à quoi te servent ces fonctions.
Une explication précise serait la bienvenue.

Précisément, je me sers de ces fonctions pour valider ou non la mise à niveau d'une table du plugin UAM:

/* Check for upgrade from 2.12 to 2.13 */
/* *********************************** */
    $fields = mysql_list_fields($conf['db_base'],USER_CONFIRM_MAIL_TABLE);
    $nb_fields = mysql_num_fields($fields);


    if ($nb_fields < 6)
    {
    /* upgrade from branch 2.12 to 2.13 */
    /* ******************************** */
      upgrade_212();
    }

Les plugins évoluent et la structure des tables qui leur sont propres aussi. :-)

Cà, c'est mon utilisation personnelle de ces fonctions. Mais, d'une manière générale, pourquoi se priver de fonctions dédiées à Mysql sous prétexte qu'elles n'existent pas nativement pour PostgreSql ou SqLite?

Si on choisit le portage sur différents systèmes de base de données, s'agissant des fonctions php, ne serait-il pas logique de pouvoir effectuer toutes les opérations que l'on souhaite sans se prendre la tête sur la présence ou non du pendant "pwg_db_###()"?

Enfin, ce n'est qu'un avis, hein! Si mon raisonnement n'est pas valide, il y aura peut-être d'autres méthodes pour arriver au même résultat mais cela compliquera un peu la chose. Et si non, tant pis pour la compatibilité de certains plugins sur d'autres bases de données.

nicolas a écrit:

Eric a écrit:

Précisément, je me sers de ces fonctions pour valider ou non la mise à niveau d'une table du plugin UAM:

Je me doutais d'une réponse comme celle-ci. C'est ton plugin. Tu gères les mises à jour et entre la 2.12 et la 2.13 tu as modifié une table. Tu n'as pas besoin de faire ces tests là. Tu sais ce que tu as modifié. Tu testes la version et tu fait un "alert table" c'est plus simple et tu es sûr de ne pas faire d'erreur.

J'apprends tous les jours ;-)
C'est évident que c'est plus simple de tester la version au lieu de la structure de la table. Merci pour le tuyau !

nicolas a écrit:

J'aurais plutôt pris le problème dans l'autre sens. Il n'y a pas de fonction mysql pour copier une table (structure) donc on écrit 25 lignes de code. Avec postgres, c'est une ligne de code. Je doute fort qu'il y ait des fonctions php majeures de mysql qui n'existent pas pour postgres ou sqlite.

(...)

Je n'ai pas dit que tout était fini. Si tu estimes qu'il manque quelque chose, tu peux créer une tâche dans mantis et coder les fonctions qu'ils manquent. Je n'ai écrit le code qu'à partir des fonctions de base.

Je ne sais pas si mysql_list_fields() et mysql_num_fields() peuvent être considérées comme des fonctions majeures. En tous cas, pour mysql_num_fields(), la correspondance avec les autres bases de données existe. Mais je n'ai rien trouvé pour mysql_list_fields().

J'ai déjà ouvert le [Bugtracker] ticket 1570

Pour ce qui est de coder les fonctions que j'estime manquer, pour MySql pas de problème. Mais PostgreSql et Sqlite, c'est une autre paire de manches... Je connais un peu PostgreSql et pas du tout Sqlite. Tu me diras, c'est en forgeant que...
Je dispose d'un peu de temps. Si tu es d'accord, je veux bien intégrer mysql_num_fields() dans le trunk. Pour mysql_list_fields(), je crains de ne pas savoir.

Je ne suis pas d'accord avec toi nicolas... c'est impossible de tester le numéro de version après une mise à jour de plugin, puisque que le numéro de version correspond au numéro de la nouvelle version! Impossible de connaitre le numéro de version précédente. C'est exactement comme ca que fonctionne l'upgrade de piwigo d'ailleurs...

J'utilise aussi ce genre de manips pour mettre à jour mes plugins (dans la fonction plugin_activate), mais pas exactement de la meme manière.
Par exemple, dans PWG Stuffs, je fais:

$query = 'SHOW TABLES LIKE "' . $prefixeTable . 'stuffs"';
$result = pwg_query($query);

if (pwg_db_fetch_row($result))
{
...
}

Ou encore...

$query = 'SHOW FULL COLUMNS FROM ' . $prefixeTable . 'stuffs;';
$result = array_from_query($query, 'Field');

if ($result[5] == 'params')
{
...
}

Mais est-ce que ces requetes sont correctes en postgre ou sqlite... aucune idée...

Ne serai-ce *que* pour aider les développeurs de plugins, l'intérêt de ces fonctions me parait évident.

Je viens de lire le post de P@t au moment où j'arrivais à la même conclusion : Tester le numéro de version n'est pas possible car il s'agit de la version à jour. Une solution serait d'ajouter le numéro de la version v-1 du plugin dans la table ###_config. On viendrait alors la lire avant de faire la mise à jour des tables. Mais tous les plugins n'ont pas forcément le besoin de stocker leur configuration tout en utilisant des tables supplémentaires.

Pouvoir tester le nombre de champs d'une table ou lister les champs d'une table me semble nécessaire.

Eric a écrit:

Mais tous les plugins n'ont pas forcément le besoin de stocker leur configuration tout en utilisant des tables supplémentaires.

rajouter une entrée dans la table CONFIG de piwigo ne coûte rien ;-)

P@t a écrit:

Je ne suis pas d'accord avec toi nicolas... c'est impossible de tester le numéro de version après une mise à jour de plugin, puisque que le numéro de version correspond au numéro de la nouvelle version! Impossible de connaitre le numéro de version précédente. C'est exactement comme ca que fonctionne l'upgrade de piwigo d'ailleurs...

Et quid des installations qui ont foirées ou des tests pour controler si une table a bien la stuture voulue.