Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1
Bonjour à tous,
Voilà en fait je voudrais mettre en place un système de cache de fichiers générés (pour une appli web, j'ai besoin de fichiers de trad pour mes javascript que je génère à partir de mon fichier de trad php et j'ai un autre besoin pour compresser mes fichiers css/js).
Je veux donc un cache tout bête mais je voudrais un cache de fichiers par hash et non par durée de vie (enfin la durée de vie peu rester mais je voudrais me baser principalement sur un hash de fichier.
Le but étant de regénérer le cache si le fichier a été modifié (pour que si une modif soit faite sur n'importe quel fichiers le cache en question soit regénéré sans attendre la fin de la durée de vie).
- Quelqu'un a-t-il déjà été confronté a ce "problème"?
- Dois gérer les hash à la mano où y'a t il des possibilités que je n'ai pas vu dans la doc?
- N'est ce pas trop lourd?
- Est ce intelligent (pour pas dire "N'est ce pas une connerie de faire ça?") ?
Merci de vos éventuels apports!
Hors ligne
Si c'est une appli web qui génère les nouveaux fichiers, elle peut pas buter le cache existant elle-même?
Hors ligne
Je veux bien quelques explications de plus alors, car je pige pas, si c'est ton appli qui génère les fichiers elle sait quand ils sont modifiées non?
Car si ils sont modif' c'est bien parce que tu les as régénérer pour moi.
Hors ligne
Pour l'instant je le génère à chaque page mais comme tu vois, c'est un peu bourrin.
Je voudrais mettre en place un test qui me permet de générer le fichier si besoin (si modifié).
Je vias mettre un système de cache avec durée de vie, mais à terme ce n'est pas la solution que je souhaite utiliser.
Hors ligne
Bonjour ,
un question bete :
ca serait pas moins couteux de comparer les dates des fichiers (fichier cache vs fichier source)?
Smarty fonctionne comme ca pour ses fichier "compilés". du coup pas de hash à calculer a chaque fois.
Hors ligne
Je viens de voir que Smary utilise filemtime() pour avoir la date de dernière modification.
Mais dans le manuel Php j'ai lu ça:
Note: Les résultats de cette fonction sont mis en cache. Voyez la fonction clearstatcache() pour plus de détails.
Avez vous des remarques à ce sujet ou ça craint si je fais avec?
Hors ligne
Bah Smarty fait avec je suppose donc soit il utilise clearstatcache() soit il bidouille mais dans les 2 cas ça doit être dans le code .
Hors ligne
Est-ce que tu as des fichiers modifiés parfois en même temps?
Est-ce que tu peut le prévoir à l'avance? Genre certains fichiers modifiés par "lots".
Car ça serait un bon cas d'exemple pour mettre ton hash en tag au lieu d'en "id de cache".
C'est juste par curiosité, t'embête pas à te compliquer la vie pour me satisfaire .
Hors ligne
J'ai un seul fichier de langue.
Car ça serait un bon cas d'exemple pour mettre ton hash en tag au lieu d'en "id de cache".
J'ai rien pigé à ta phrase ou alors on parle pas la même langue
Hors ligne
Après réflexion j'ai dis un peu n'imp, le hash n'est pas vraiment utilisable en tant que tag.
Je m'explique quand même.
On peut identifier un truc en cache par un id, ça permet entre autres de buter un truc en cache en fournissant son id à la fonction qui va bien, c'est sûrement ce que tu utilises.
Voir même pas en fait si t'as qu'un seul truc à cacher mais ça change rien.
Là où c'est bien foutu c'est qu'en plus de l'id, on peut tagguer nos caches, et ça permet de buter d'un coup tous les caches qui possèdent un tag en communs.
Un exemple tout bête c'est si je cache par exemple une 50aine de trucs en HTML.
Seulement 30 chargent un script JS, bah je les tag "JS".
Comme ça si je change mon script JS, genre je le met à jour, je dis à mon moteur de cache de buter seulement les pages tagguées "JS".
Dans ton cas on s'en tape effectivement car vu que c'est du hash, ça sera de toute façon unique par fichier .
Hors ligne
Salut Nikkau,
A priori un hash n'est pas unique. Bon il ne faudrait pas avoir de bol pour avoir 2 fichiers avec le même hash... certes... mais c'est théoriquement possible.
A+, Philippe
Hors ligne
On est d'accord, il est évident qu'il existe plus de contenu de fichier différents possibles et que de hash différents possibles.
Maintenant dans le contexte, on génère ce hash justement pour son côté unique donc on va considérer qu'il l'est .
Mais bon la solution finale choisie est mieux, la probabilité d'une collision est encore moins présente comme ça.
Hors ligne
Pages: 1