#209: (...) En conséquence, introduction d'un variante d'abstraction, '''sql_updateq'''
Ne pourrait-on pas améliorer en disant qu'une seule fonction
(sql_update) saurait traiter les deux cas : les paramètres de mise à
jour sous forme de chaine ou de tableau ?
-- Fil
Je ne suis pas sûr de comprendre la proposition. Là, la question c'est qu'il y a des cas où je veux dire (pour une table qui a des champs nommés "champ1" et "champ2") SET champ1='champ2' (j'affecte à une constante) et d'autre où je veux dire SET champ1=champ2 (je recopie champ2 dans champ1) avec la contrainte supplémentaire que l'sage des apostrophes est conditionné par le type de serveur SQL (donc ça ne doit pas se voir dans le code de SPIP hors fonction d'abstraction).
Maitenant, le fait de donner un tableau ou une chaine, on avait eu une discussion là-dessus qui penchait plutot en faveur du tableau, qui me semble maintenant carrément indispensable vu qu'on a besoin du nom du champ pour indexer le tableau décrivant la table.
Committo,Ergo:Sum
c'est qu'il y a des cas où je veux dire (pour une table qui a des
champs nommés "champ1" et "champ2") SET champ1='champ2' (j'affecte à
une constante) et d'autre où je veux dire SET champ1=champ2 (je
recopie champ2 dans champ1) avec la contrainte supplémentaire que
Ah OK, c'est moi qui n'avais pas compris. Il y a aussi des cas
pénibles avec SET champ=NOW(), et SET x=0xhexa
-- Fil
Bah justement l'introduction de la variante updateQ a pour but de traiter ces cas là.
C'est expliqué là:
http://trac.rezo.net/trac/spip/changeset/10009
mais il faut lire les logs, je passe assez de temps à les rédiger.
Committo,Ergo:Sum
* Committo,Ergo:sum tapuscrivait, le 20/08/2007 08:45:
c'est qu'il y a des cas où je veux dire (pour une table qui a des
champs nommés "champ1" et "champ2") SET champ1='champ2' (j'affecte à
une constante) et d'autre où je veux dire SET champ1=champ2 (je
recopie champ2 dans champ1) avec la contrainte supplémentaire queAh OK, c'est moi qui n'avais pas compris. Il y a aussi des cas
pénibles avec SET champ=NOW(), et SET x=0xhexaBah justement l'introduction de la variante updateQ a pour but de traiter ces cas là.
C'est expliqué là:
http://trac.rezo.net/trac/spip/changeset/10009
mais il faut lire les logs, je passe assez de temps à les rédiger.
ça ne résoud pas les referers des stats qui utilisent dans genie/visites.php :
// ajouter les visites
foreach ($ar as $num => $liste) {
spip_query("UPDATE spip_referers SET visites = visites+$num, visites_jour = visites_jour+$num WHERE ".calcul_mysql_in('referer_md5',$liste));
}
Qui fait donc appel à :
function calcul_mysql_in($val, $valeurs, $not='') {
if (is_array($valeurs))
$valeurs = join(',', array_map('_q', $valeurs));
Voir : http://thread.gmane.org/gmane.comp.web.spip.devel/42432
ça ne résoud pas les referers des stats qui utilisent dans
genie/visites.php :
// ajouter les visites
foreach ($ar as $num => $liste) {
spip_query("UPDATE spip_referers SET visites = visites+$num,
visites_jour = visites_jour+$num WHERE
".calcul_mysql_in('referer_md5',$liste));
}
Voir : http://thread.gmane.org/gmane.comp.web.spip.devel/42432
Ce bug est résolu par [10134], on appelle calcul_mysql_in en mode
"texte" et pas "array", poru éviter _q().
-- Fil