Problème de rafraichissement avec Globaliz e (bug du cache

Bonjour !

J’ai un problème de “rafraîchissement” avec Globalize sur les textes
statiques (<%=“mon_texte”.t%>).

Quand Je modifie la traduction, celle-ci n’est prise en compte qu’après
redémarrage du serveur (mongrel). Hors, la nouvelle traduction a bien
été enregistrée en base (table globalize_traductions).

Pour tester, j’ai utilisé 2 méthodes différentes pour afficher dans la
vue le même texte traduit :

<%= “mon texte”.t %> : méthode classique, le “rafraîchissement” ne
fonctionne pas

Et

<%= mon_objet_ViewTranslation.text %>: là par contre le
“rafraîchissement” fonctionne et j’obtiens mon texte modifié

Il me semble que le problème vienne d’une mauvaise gestion du système de
cache de Globalize
(globalize/lib/globalize/localization/db_view_translator.rb)…

En effet, pour tester j’ai dévalider la gestion du cache de Globalize
((globalize/lib/globalize/localization/db_view_translator.rb) :

  def fetch_from_cache(key, language, real_default, num, namespace =

nil)
return real_default if language.nil?

    zero_form   = num == 0
    plural_idx  = language.plural_index(num)        #

language-defined plural form
zplural_idx = zero_form ? 0 : plural_idx # takes zero-form into
account

#—Suppression de la gestion du cache pour test—

cached = cache_fetch(key, language, zplural_idx, namespace)

if cached

result = cached

else

      result = fetch_view_translation(key, language, zplural_idx,

namespace)

      # set to plural_form if no zero-form exists
      result ||= fetch_view_translation(key, language, plural_idx,

namespace) if zero_form

      cache_add(key, language, zplural_idx, result, namespace)

end

    result ||= real_default
  end

Et là … bingo ça fonctionne…par contre je n’ai plus de gestion de
cache à l’affichage…pas top

J’ai vu dans l’api de Globalize que la classe
Globalize::DbViewTranslator possédait une méthode cache_reset() qui
pourrait être utile (ma première idée serait de faire un raz du cache Ã
chaque fois que je modifie une traduction pour forcer la lecture en
base)

Avant d’aller plus loin dans ma réflexion, quelqu’un a-t’il déjà eu ce
problème ? Et trouver une solution ?

Merci pour toutes vos réponses.

J.


Pickabee
Communication Visuelle & Multimédia
6 rue Jacques de la Roque - 13100 Aix-en-Provence
Tél. 04 42 96 98 13 - 06 32 60 31 86
http://www.pickabee.com

J’ai vu dans l’api de Globalize que la classe
Globalize::DbViewTranslator possédait une méthode cache_reset() qui
pourrait être utile (ma première idée serait de faire un raz du
cache à chaque fois que je modifie une traduction pour forcer la
lecture en base)

C’est un peu hardcore de supprimer tout le cache juste pour une
clef… :wink:

Avant d’aller plus loin dans ma réflexion, quelqu’un a-t’il déjà eu
ce problème ?

oui

Et trouver une solution

utilise invalidate_cache (ligne 102 de db_view_translator.rb)


RailsFrance - http://www.railsfrance.org
Paris on Rails - http://forum.parisonrails.org

Merci Richard pour cette réponse,

Le lundi 28 mai 2007 à 16:07 +0200, Richard P. a écrit :

J’ai vu dans l’api de Globalize que la classe
Globalize::DbViewTranslator possédait une méthode cache_reset() qui
pourrait être utile (ma première idée serait de faire un raz du
cache à chaque fois que je modifie une traduction pour forcer la
lecture en base)

C’est un peu hardcore de supprimer tout le cache juste pour une
clef… :wink:

^^

Avant d’aller plus loin dans ma réflexion, quelqu’un a-t’il déjà eu
ce problème ?

oui

Et trouver une solution

utilise invalidate_cache (ligne 102 de db_view_translator.rb)

Super nickel ça marche ! Un grand merci :slight_smile:

(Vive les private methods non documentées ! )

Jérémy.


Pickabee
Communication Visuelle & Multimédia
6 rue Jacques de la Roque - 13100 Aix-en-Provence
Tél. 04 42 96 98 13 - 06 32 60 31 86
http://www.pickabee.com

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs