je suppose que lorsqu'on lance un script, une seule connexion à la
base de donnée est initiée et l'api sql_* utilise toujours cette
connexion.
Or dans un cas où le script est particulièrement long, la connexion
est coupée en cours de route
Au résultat
Mysql : "Mysql goes away",
Sqlite : "database is locked - "
Il semblerait que sql_free ne soit pas très utile vu que le code
incriminé n'utilise pas fonction sql_* gérant des resources
Marcimat propose unset
(http://trac.rezo.net/trac/spip/changeset/11288) mais meme remarque je
ne vois pas où l'utliiser.
Donc je ne sais pas si c'est mon code qui est foireux ou si c'est un
pb avec l'api sql_*
On peut tester le tout en mettant dans un spip divers document de type
pdf, lancer la page ?page=doc2imgall et regarder les log mysql.log ou
sqlite.log
probablement ni l'un ni l'autre: si ton script est trop long la connexion est coupée c'est tout. Quant a sql_free, son rôle est justement de dispenser les gens de devoir penser au Hack de Mathieu car c'est abscons. Pour moi le reproche à faire dans l'interface sql_ actuelle, c'est que sql_free devrait n'apparaitre que dans les fonctions d'abstraction, pas dans le code de SPIP proprement dit. Autrement dit il faudrait n'utiliser que sql_fetsel et sql_getfetsel et qq autres à trouver pour que sql_fetch ne soit plus utile directement. Mais ça n'a rien à voir avec ton pb.
justement de dispenser les gens de devoir penser au Hack de Mathieu car c'est abscons.
Oui, d'ailleurs, pour cet exemple, sql_free($res); devrait aller si je comprends la syntaxe.
à condition que je modifie spip_sqlite_free($r) qui pour l'instant ne fait rien ! unset($r) devrait aller je présume, vu qu'il n'existe pas de fonctions sqlite_free ou $PDO->free() ...