invalidateur et spip 2.

Général
1

Bonjour,

Je suis actuellement en train de développer quelques plugins pour me faire la main.
Dans l'un d'entre eux, j'ai un système de messagerie avec formulaires etc.
Mon problème est le suivant: j'ai créé un formulaire "marquer comme lu" qui lorsque l'on clique dessus positionne un flage en base se donnée sur le message, et redirige vers une page qui l'affiche. Jusque la, tout va bien.
Par contre, la ou cela ne va pas, c'est quand on revient à la boite de réception: malgré un cache à 0, j'ai visiblement un souci.
Un message fraichement lu n'est affiché comme tel qu'après un rafraichissement de cette page ( il faut donc revenir à la boite de réception, et la rafraichir pour être à jour ).

Ce que je décris est ce que je constate généralement. Ceci dit, quand un délai important s'écoule entre la lecture du message, et le retour sur la boite, elle semble apparaitre directement à jour. J'avoue donc que je m'y perds un peu ...

J'ai cherché de la documentation sur l'invalidateur du cache de spip et n'en ai trouve que peu. Visiblement la série 1.X.X utilisait la base de donnée et on pouvait invalider tel ou tel cache selon des critères donnés ( id objet etc ). En me balladant dans inc/invalidateur, j'ai constaté que cela ne semblait pas se passer comme ça pour la 2.X.X.
Si j'ai bien compris, cette version se base sur un cache sans base basé uniquement sur les dates. Et l'invalidateur se contente de renseigner une méta qui rend obsolète tout ce qui lui est antérieur dans le cache.

J'ai bien tenté de confirmer cela en appelant "suivre_invalideur()" dans mon plugin, mais cela ne semble pas avoir corrigé le souci ...

Du coup si certains d'entre vous ont des infos/ des pistes, je suis bien preneur ...

Merci !

Vincent

2

C'est peut être le cache de ton navigateur ici qui accélère ta navigation...
JLuc
Vincent a écrit :

Bonjour,

Je suis actuellement en train de développer quelques plugins pour me faire la main.
Dans l'un d'entre eux, j'ai un système de messagerie avec formulaires etc.
Mon problème est le suivant: j'ai créé un formulaire "marquer comme lu" qui lorsque l'on clique dessus positionne un flage en base se donnée sur le message, et redirige vers une page qui l'affiche. Jusque la, tout va bien.
Par contre, la ou cela ne va pas, c'est quand on revient à la boite de réception: malgré un cache à 0, j'ai visiblement un souci.
Un message fraichement lu n'est affiché comme tel qu'après un rafraichissement de cette page ( il faut donc revenir à la boite de réception, et la rafraichir pour être à jour ).

Ce que je décris est ce que je constate généralement. Ceci dit, quand un délai important s'écoule entre la lecture du message, et le retour sur la boite, elle semble apparaitre directement à jour. J'avoue donc que je m'y perds un peu ...

J'ai cherché de la documentation sur l'invalidateur du cache de spip et n'en ai trouve que peu. Visiblement la série 1.X.X utilisait la base de donnée et on pouvait invalider tel ou tel cache selon des critères donnés ( id objet etc ). En me balladant dans inc/invalidateur, j'ai constaté que cela ne semblait pas se passer comme ça pour la 2.X.X.
Si j'ai bien compris, cette version se base sur un cache sans base basé uniquement sur les dates. Et l'invalidateur se contente de renseigner une méta qui rend obsolète tout ce qui lui est antérieur dans le cache.

J'ai bien tenté de confirmer cela en appelant "suivre_invalideur()" dans mon plugin, mais cela ne semble pas avoir corrigé le souci ...

Du coup si certains d'entre vous ont des infos/ des pistes, je suis bien preneur ...

Merci !

Vincent

3

JLuc a écrit :

C'est peut être le cache de ton navigateur ici qui accélère ta navigation...
JLuc

J'avais déjà plus ou moins gratté dans cette direction, et il ne s'agit visiblement pas de ça.
Sinon, après quelques recherches supplémentaire, l'invalidateur semble bien fonctionner comme je le décrivais.
On peut accéder à la valeur en question dans un squelette comme ça :
invalidateur : #EVAL{ date( 'd/m/Y H:i:s', $GLOBALS['meta']['derniere_modif'] ); }

Du coup, sur un appel à l'invalidateur, tout le cache devient d'un coup intégralement obsolète.
Cela me parait bigrement surprenant, mais sinon, je ne m'explique pas le fonctionnement de cette valeur ...
( dans la fonction suivre_invalideur() du fichier inc/invalidateur.php ).

Le commentaire correspondant ne m'éclaire pas des masses :
// Invalider les caches lies a telle condition
// ici on se contente de noter la date de mise a jour dans les metas

Bon sang, c'est mal engagé mon affaire ...

4

Le 26/10/2009 13:34, Vincent a écrit :

Du coup, sur un appel à l'invalidateur, tout le cache devient d'un coup
intégralement obsolète.
Cela me parait bigrement surprenant, mais sinon, je ne m'explique pas le
fonctionnement de cette valeur ...
( dans la fonction suivre_invalideur() du fichier inc/invalidateur.php ).

Avant 2.0, le cache était géré en fonction des objets et id_objet, et chaque élément pouvait être invalidé indépendamment.

Il s'est trouvé que le cout de performance de cette technique n'était pas excellente et invalider *tout* le cache lorsqu'on appelle l'invalideur (pour donc forcer des calculs nouveaux) était à la fois bien plus simple techniquement, et moins gourmand. C'est maintenant ce qui est fait en SPIP 2.0

Reste que si tu appelles suivre_invalideur(), après la mise à jour de la base, ton contenu devrait se mettre à jour… Il y a un truc à trouver :slight_smile:

--
MM.

5

Avant 2.0, le cache était géré en fonction des objets et id_objet, et chaque élément pouvait être invalidé indépendamment.

C'est ce que j'avais cru comprendre en me balladant sur le net.

Il s'est trouvé que le cout de performance de cette technique n'était pas excellente et invalider *tout* le cache lorsqu'on appelle l'invalideur (pour donc forcer des calculs nouveaux) était à la fois bien plus simple techniquement, et moins gourmand. C'est maintenant ce qui est fait en SPIP 2.0

Oui, j'imagine que sur un site un peu joufflu, cela devait causer des appels coûteux en base ... Ceci dit, j'ai sacrément intérêt à me méfier de l'invalidateur du coup .
Car si je dynamite le cache à chaque fois, cela ne va pas être super pour les performances ! ^^

Reste que si tu appelles suivre_invalideur(), après la mise à jour de la base, ton contenu devrait se mettre à jour… Il y a un truc à trouver :slight_smile:

Oui, je me doutais que mon souci devait être un truc tout bête. Ta réponse m'a mis sur la bonne voie !
J'ai commencé par flanquer brutalement un "$GLOBALS['var_nocache']=true;" dans mes options.
La, ôh surprise: tout fonctionnait correctement, y compris en supprimant mon appel à l'invalideur dans mon formulaire.

Au final, j'ai trouvé ma boulette: la partie affichant les massages marqués comme "lus" en base est appelée via un include par une page avec un cache non nul ...

On dirait donc que lors d'un include, même si la partie incluse à un cache à "0", cela pose des problèmes. Peut être du aux headers http ?
Je n'ai pas (encore?) le fin mot de l'histoire, mais je suis hors d'eau, ce qui est déjà super.

Un grand merci pour ce retour donc !

Vincent ( Spipien heureux )