Log:
Encore une amélioration à la gestion du cache des metas: le fichier n'est pas détruit mais seulement anti-daté. Spip le reconstruira lorsqu'il verra qu'il est anti-daté, mais cela permet aux informations considérées comme pérennes d'être accessibles même lorsque la base ne l'est pas pour une raison (panne) ou pour une autre (accès conditionné par la base elle-même). Cette stratégie tempère le défaut d'un cache qui ne fait pas dans le détail des meta (on n'est pas au niveau du Hard, faut faire avec) et pourrait encore être améliorée: les appels de lire_meta() provoquent une relecture complète SQL, c'est excessif (quelques uns sont éliminés avec ce dépot).
Le fichier inc/meta étant à présent systématiquement chargé dans inc/utils, toutes ses inclusions disparaissent, ainsi que deux appels à l'antique lire_meta().
les appels de lire_meta() provoquent une relecture complète SQL, c'est excessif
Attention : quand on synchronise des choses sensibles via les meta, on
tient absolument à avoir une info fraîche venant de SQL. Car elle a pu
changer depuis la dernière fois qu'on a fait lire_meta(). Les
princiaples difficultés sont dans les invalidations (être sûr qu'on
envoie la page avec le forum qu'on vient de poster), et dans les cron,
souvent longs (mais ça tu l'as maintenant réglé autrement je pense).
les appels de lire_meta() provoquent une relecture complète SQL, c'est excessif
Attention : quand on synchronise des choses sensibles via les meta, on
tient absolument à avoir une info fraîche venant de SQL. Car elle a pu
changer depuis la dernière fois qu'on a fait lire_meta(). Les
princiaples difficultés sont dans les invalidations (être sûr qu'on
envoie la page avec le forum qu'on vient de poster), et dans les cron,
souvent longs (mais ça tu l'as maintenant réglé autrement je pense).
Tous les chgts dans la table spip_meta se font à travers ecrire_meta() qui écrit aussi dans la globale, donc le pb vient exclusivement de ce que lire_meta lit le cache au lieu de faire un appel à SQL (du moins si on néglige la question des accès concurrents, mais c'est la boite de Pandore, on le sait). Les appels qui restent sont problématiques plutot sur les scripts susceptibles de time-out, lesquels sont surtout concernés par leur numéro d'étape et truc de ce genre. Je ne prends pas le risque, j'en ai assez pris ces jours-ci, mais je pense que ça pourrait se limiter à la relecture de ces infos précises.
(du moins si on néglige la question des accès concurrents, mais c'est la
boite de Pandore, on le sait).
Quand même, repasser par SQL permet de régler le problème des accès
concurrents ; c'est bien de ça qu'il s'agit quand on refait
lire_meta().
Par ailleurs je ne sais pas si tous les OS vont apprécier le
touch(x,0) et vraiment renvoyer 0 (EPOCH) comme filemtime() ; on
devrait mettre une vieille date, mais 0 ça me paraît risqué. Ou alors
on se dit qu'on verra bien
(du moins si on néglige la question des accès concurrents, mais c'est la
boite de Pandore, on le sait).
Quand même, repasser par SQL permet de régler le problème des accès
concurrents ;
bah non parce que ton while (meta=fetch()) il peut etre interrompu entre 2 itérations, du coup tu peux te retrouver avec une liste de meta qui n'est ni l'ancien état ni le nouveau. C'est les limitations de MySQL.
c'est bien de ça qu'il s'agit quand on refait
lire_meta().
Par ailleurs je ne sais pas si tous les OS vont apprécier le
touch(x,0) et vraiment renvoyer 0 (EPOCH) comme filemtime() ; on
devrait mettre une vieille date, mais 0 ça me paraît risqué. Ou alors
on se dit qu'on verra bien
le touch(0) c'est la naissance d'Unix, c'est que W*ind*ws va peut-etre en profiter pour ostraciser.
Tu propose de prendre la naissance de SPIP ?
(du moins si on néglige la question des accès concurrents, mais c'est la
boite de Pandore, on le sait).
Quand même, repasser par SQL permet de régler le problème des accès
concurrents ; c'est bien de ça qu'il s'agit quand on refait
lire_meta().
Par ailleurs je ne sais pas si tous les OS vont apprécier le
touch(x,0) et vraiment renvoyer 0 (EPOCH) comme filemtime() ; on
devrait mettre une vieille date, mais 0 ça me paraît risqué. Ou alors
on se dit qu'on verra bien
Attention on a eu des soucis sur les filtres images chez free a cause de filemtime qui provoquait une erreur en cas de fichier absent.
Il semble qu'il faille preceder le filemtime d'un file_exist, ou alors inverer le lire_fichier et le filemtime pour se prémunir de cela
cf http://forum.spip.org/fr_189983.html et plus generalement filemtime free - Recherche Google
Par ailleurs je ne sais pas si tous les OS vont apprécier le
touch(x,0) et vraiment renvoyer 0 (EPOCH) comme filemtime() ;
on devrait mettre une vieille date, mais 0 ça me paraît
risqué. Ou alors on se dit qu'on verra bien
Si c'est un format timestamp, tu peux mettre 1 à la place de 0, on est pas à
une seconde près...
Le 27 sept. 07 à 16:11, cedric.morin@yterium.com a écrit :
Attention on a eu des soucis sur les filtres images chez free a cause de filemtime qui provoquait une erreur en cas de fichier absent.
Il semble qu'il faille preceder le filemtime d'un file_exist, ou alors inverer le lire_fichier et le filemtime pour se prémunir de cela
cf http://forum.spip.org/fr_189983.html et plus generalement filemtime free - Recherche Google
Quelle horreur. Amélior" dans 10441, mais ne faudrait-il pas alors revoir tous les filemetime ?
