bug maj spip_article par le cron visites et popularité PGSQL
SPIP 2.1.2 et PGsql 8.3
Avec pgsql, nous avons une fonction spip_pg_ajouter_champs_timestamp qui est exécuté sur un appel de spip_pg_update et aussi spip_pg_updateq. Cette fonction n'existe pas sous mysql et semble exister sous sqlite_generique aussi.
Cette fonction pose le problème suivant lors de mise à jour des information de visites et de popularité par le cron. En effet les date qui sont de type timestamp (date, date_redac, et date_modif) sont mise à jour en même temps que la colonne visite et popularité avec un NOW(). Du coup tout les articles changent de date s'il ont été visité le jour en question... C'est vraiment pas terrible.
-Soit on désactive la fonction dans spip_pg_update (
ecire/req/pg.php
844-- couples = spip_pg_ajouter_champs_timestamp(
table, $couples, $desc, $serveur);
844++ //couples = spip_pg_ajouter_champs_timestamp(
table, $couples, $desc, $serveur);
-Soit on évite que les colonne date,date_redac et date_modif ne soit ajouté à la liste des colonnes dans la fonction en question : ecrire/req/pg.php 188++ if ($maj!="date" && $maj!="date_redac" && $maj!="date_modif")
-Soit on modifie visites et popularites en rajoutant les 3 champs de date que l'on ne veut pas modifier ecrire/genie/visites.php 135++ 'date' => 'date','date_modif' => 'date_modif','date_redac' => 'date_redac'
-Soit cette fonction n'aurait pas du trouver ces champs de date et alors on corrige cette fonction (je sais pas comment faire now)
Voila les logs de BDD qui m'ont permis de comprendre le bug
2010-10-05 16:02:05 CEST LOG: durée : 1.826 ms, instruction : UPDATE spip_articles SET visites=visites+1,popularite=popularite+1.39,maj=maj, date=NOW(),date_redac=NOW(),date_modif=NOW() WHERE ((id_article IN (381,360,345)))
2010-10-05 16:35:43 CEST LOG: durée : 3.714 ms, instruction : UPDATE spip_articles SET maj=maj,popularite=popularite * 0.851732450769, date=NOW(),date_redac=NOW(),date_modif=NOW() WHERE popularite>1