openMairie.org | Démonstration | Documentation | Forum

Suggestion d'amélioration OM4.10-dev

Avec OM4.9.6 et PHP 7.4, quand on utilise le générateur on obtient l’alerte:

Notice: Trying to access array offset on value of type null in /var/www/html/oem/php/db/DB/pgsql.php on line *1000*

On pourrait remplacer la ligne 1000 :
$num = preg_replace("/'(.*)'::\w+/", "\\1", $row[0]);
par
$num=0;
if ( is_array($row) ) {
$num = preg_replace("/'(.*)'::\w+/", "\\1", $row[0]);
}

Bonjour Laurent,

Je ne reproduis pas ni sur la version OM4.9.7 ni sur la version OM4.9.6. J’ai joué les tests sur toutes les versions de PHP de 5.6 jusqu’à 7.4 et je n’ai aucune notice ni même aucun deprecated.

La 4.9.7 met à jour la librairie dont tu parles. Tu peux essayer de nouveau et/ou décrire ton cas d’utilisation précis sur le générateur ? Les tests font une génération complète sur le framework et vérifient le fonctionnement standard des assistants, peut-être que ton cas d’utilisation peut venir augmenter la couverture actuelle de tests du générateur.

Florent

Bonjour,

Merci de ce retour, je viens de ré-essayer sur OM 4.9.7 avec ma config, et je le reproduis en effet :

  • Apache PHP
    • 7.4.5 sur Ubuntu 18.04
      -module Pgsql: PostgreSQL(libpq) => PostgreSQL 10.12 (Ubuntu 10.12-0ubuntu0.18.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0, 64-bit
  • PostgreSQL : Ubuntu 12.2-2.pgdg18.04+1

Si je génère manuellement om_collectivite : app/index.php?module=gen&view=gen_generate&table=om_collectivite

  • Aucune alerte

Si je génère manuellement om_dashboard : app/index.php?module=gen&view=gen_generate&table=om_dashboard

  • 41 alertes concernant DB_pgsql->TableInfo() puis DB_pgsql->_pgFieldFlags() :
    • 10 déclenchées par gen->check_om_validite()
    • 26 déclenchées par gen->get_libelle_of() , elle-même appelée par gen->def_obj_meth_get_var_sql_forminc__sql()
    • 5 déclenchées directement par gen->def_obj_meth_get_var_sql_forminc__sql()
  • C’est notamment la présence de clé étrangère qui déclenche le problème, si les tables de ces clés étrangères ont des champs avec valeur ‹ DEFAULT ›
  • En creusant la première alerte, je trouve que DB_pgsql->_pgFieldFlags() tombe en alerte :
    • en analysant la table om_profil, sur le champ hierarchie
    • une première requête sur le catalogue de la base ( pg_attribute.atthasdef) a indiqué un champ avec une valeur par défaut
      -une seconde requête sur le catalogue ( pg_attrdef.adsrc ) cherche à déterminer cette valeur par défaut et déclenche une erreur silencieuse ( exécutée avec le préfixe @) : " la colonne a.adsrc n’existe pas"

En effet, nous pouvons lire dans les notes de version de PostrgreSQL 12 :

Remove obsolete pg_attrdef . adsrc column (Peter Eisentraut)

La documentation de la version 11 sur pg_attrdef nous fait comprendre qu’il faut s’appuyer sur le champ adbin, qui devrait nécessiter d’être éventuellement interprété.

Donc il semble que pear.php.net/package/DB n’est pas adapté à PostgreSQL 12, avec un impact probablement limité au générateur (pg_catalog) car le SQL est généralement très stable :

  • soit on utilise véritablement cette fonctionnalité … et peut-être d’autres similaires dans d’autres cas, et alors
    • soit il faut essayer de corriger DBpear, peut-être en s’appuyant sur les tests automatiques plutôt que de requalifier entièrement le générateur
    • soit on renonce à PostgreSQL 12 tant qu’on a pas migré sur un autre connecteur DB (PDO ?) et on endure les critiques de sécurité moindre
  • soit on ne l’utilise pas véritablement, et on peut peut-être utiliser mon contournement grossier via une version OM de DBPEAR , comme on a des version OM de om-theme …
    • il semble en effet que la valeur par défaut n’est pas exploité, car on note l’absence de définition de méthode get_default_values() dans les classes générées (exple: om_etat.margeleft qui a DEFAULT=10)
    • il faudrait alors s’en assurer par des tests automatiques
    • mais gérer une version OM d’un composant externe, c’est du travail qui ne va pas dans le sens de l’évolution du framework

Remercions au passage notre ami Peter Eisentraut pour avoir fait du ménage ;o)