Je ne sais pas pourquoi, mais dans le code de SPIP, PG a besoin de chercher un champ ‘timestamp seul’ de la table pour les sql_insertq() afin de les mettre à jour.
Cela introduit une convention qui n’est pas respectée dans SVP - et donc un bug :
extrait de ecrire/req/pg.php :
function spip_pg_ajouter_champs_timestamp($table, $couples, $desc=’’, $serveur=’’){
…
// recherche des champs avec simplement ‘TIMESTAMP’
// cependant, il faudra peut etre etendre
// avec la gestion de DEFAULT et ON UPDATE
// mais ceux-ci ne sont pas utilises dans le core
…
}
Exemple d’appel dans le même fichier :
function spip_pg_insertq_multi($table, $tab_couples=array(), $desc=array(), $serveur=’’,$requeter=true) {
…
// recherche de champs ‘timestamp’ pour mise a jour auto de ceux-ci
// une premiere fois pour ajouter maj dans les cles
$les_cles = spip_pg_ajouter_champs_timestamp($table, $tab_couples[0], $desc, $serveur);
Cet appel va foirer avec SVP qui n’a pas de champ de type ‘maj’ - Et donc vlan! pour le array_keys
Quelle est la meilleur approche à votre avis ?
Rajouter dans spip_plugins un champ ‘maj’ pour PG ? Ou permettre à une table de ne pas avoir de champ de type mise à jour (et donc modifier le code de SPIP) ?
Regarde comment c'est fait avec SQLite qui a le même code. Peut être ce code a évolué depuis. Le truc est de faire traduire le «On update current_timestamp» de Mysql par PG ou SQLite.
Par ailleurs, ton analyse semble erronée lorsque tu dis «Cet appel va foirer avec SVP qui n'a pas de champ de type 'maj' - Et donc vlan! pour le array_keys» car la fonction *_ajouter_champs_timestamp() est prévue pour retourner tous les couples (timestamp ou non) de la table, et retourne toujours un array au minimum.
Si problème il y a (ce qui ne me semble pas le cas), il n'est, si je comprends bien, pas celui que tu indiques en tout cas.
Peut être devrais tu expliquer l'erreur que tu as eu ?
La différence entre sqlite et pg c’est que sous sqlite on vérifie que le tableau retourné par spip_XX_ajouter_champs_timestamp() est non vide avant de lui appliquer array_keys()
Ouaip.
Je pense que ça serait plus facile de trouver l'erreur si tu affichais des infos avec xdebug (genre le contenu des variables qui entrent dans la fonction).
Cela dit la ligne 869 devrait je pense être avec array() à la place de $tab_couples[0] comme dans spip_sqlite_insertq_multi(), car si $tab_couples n'a pas de couples, ça retourne NULL. C'est ptet le souci.
// une premiere fois pour ajouter maj dans les cles
$les_cles = spip_pg_ajouter_champs_timestamp($table, array(), $desc, $serveur);
je rappèle que l'implémentation PG est fondamentalement bugguée puisqu'elle ne sait pas renvoyer avec certitude l'id après une insertion, et est susceptible de renvoyer un id faux en cas de 2 insertions concurrentes sur la même table.
Je n'ai pas trouvé de solution à ce problème et du coup j'avais laissé tombé la résolution des tickets ouverts sur PG.
Tant que tu es sur le sujet, n'hésite pas à regarder les tickets ouverts et ce problème fondamental d'insertion en base.
