un Desarrollador Web Freelance

Revisando el log de tus queries te puedes encontrar que si estás buscando registros por un campo VARCHAR te salte un warning de “long key length“.

Esto es porque el índice que has puesto en este campo VARCHAR es muy grande, aunque MySQL soporta índices de hasta 1000 bytes si son muy grandes pueden ralentizar las búsquedas.

La solución está en limitar el tamaño del índice a un número bastante pequeño.

En MySQL esto se indica así:

ALTER TABLE mi_tabla ADD INDEX ( campo_del_indice(4) )

ó también:

CREATE  INDEX `nombre_del_indice` ON mi_tabla (`campo_del_indice`(4))

El problema es que si estamos usando ‘migrations‘ de Rails y queremos ser puristas nos encontramos con que la sintaxis estándar de las migraciones de Rails no soporta el campo ‘longitud’.

Como bien dice Jaime Iniesta existe un parche que da soporte a las migraciones para admitir el campo ‘length’.

Yo sin embargo he preferido no tocar el código de mis gemas y meter este fichero (rails_migraions_hack.rb) en el ‘/lib‘ de mi aplicación:

module ActiveRecord
  module ConnectionAdapters # :nodoc:
    module SchemaStatements
      def add_index(table_name, column_name, options = {})
        column_names = Array(column_name)
        index_name   = index_name(table_name, :column => column_names)
 
        if Hash === options # legacy support, since this param was a string
          index_type = options[:unique] ? "UNIQUE" : ""
          index_name = options[:name] || index_name
          index_length = options[:length] ? "(#{options[:length]})" : nil # only mysql
        else
          index_type = options
        end
        quoted_column_names = column_names.map { |e| quote_column_name(e) }.join(", ")
        # execute "CREATE #{index_type} INDEX #{quote_column_name(index_name)} ON #{quote_table_name(table_name)} (#{quoted_column_names})"
        sql = "CREATE #{index_type} INDEX #{quote_column_name(index_name)} ON #{table_name} (#{quoted_column_names}#{index_length})"
        p "SQL: #{sql}"
        execute sql
      end
    end
  end
end

Y cargarlo con un:

require 'rails_migrations_hack'

En mi environment.rb.

Funciona perfectamente y vemos como saca por pantalla las querys de las creaciones de índices con cosas como esta:

"SQL: CREATE  INDEX `idx_forums_forums_nicetitle` ON forums_forums (`nicetitle`(4))"

Es interesante consultar toda la discusión en la lista de ror-es.

Actualizado (2008-08-13):

Al parecer no estan cubiertas todas las posibilidades.

En el caso de estar creando un índice compuesto el atributo length se lo asigna al último campo y esto puede no ser lo adecuado:

add_index :tabla, [:campo1, :campo2], :name => 'idx_tabla1', :length => '10'

lo que intenta es hacer:

CREATE  INDEX `idx_tabla1` ON tabla (`campo1`, `campo2`(10))

Si el campo varchar que queremos limitar es el primero la hemos cagado..

Habría que intentar modificar la sintaxis del length para que coja algo como esto:

add_index :tabla, [:campo1, :campo2], :name => 'idx_tabla1', :length => { :campo1 => '10' }

No sé si es que soy yo el liante o es que me da por hacer las cosas raras.

El caso es que me he encontrado con otro dolor de cabeza haciendo algo, en principio, relativamente sencillo.

Se trata de insertar en la BD un modelo desde un script, que más adelante será un rake. Todo iba bien, no es complicado:

m = MiModelo.new( :nombre => 'el nombre' )
m.save

Pero, algo olía mal, pues los listados de este modelo tienen una vista, y esta vista está cacheada, y si insertaba el modelo desde el script la vista no cambiaba, osea: no estaba expirando la caché.

El problema estaba en que todos los engranajes de expiración de cachés estaban en los sweepers y éstos sólo se activan si el código pasa por el application.rb, padre de todos los controladores, concretamente con el método: cache_sweeper, y no encontraba manera de activar los sweeper sin pasar por un controlador.

Estuve dando unas buenas vueltas y preguntando a colegas, resulta que la caché en Rails está altamente integrada con el controlador. Y esto tiene su sentido pues no hay caché sin renderizado y no hay renderizado sin llamada a un controlador. Pero cuando hablamos de expirar cachés no veo tan claro que deba seguir estando integrado con el controlador, pues, como vemos en mi ejemplo del script, pueden existir muchos escenarios donde sea necesaria una expiración de caché sin necesidad de pasar por un controlador.

Googleando por ahí encontré un post que según creo entender también se queja un poco del exceso de integración entre la caché y los controladores.

La primero aproximación que parece ocurrírsenos es la de usar un observer en vez de un sweeper pero el sweeper tiene implícitamente un montón de métodos muy útiles para realizar la tarea de expiración de caché, como son los expire_* y los renderizadores de urls al estilo mi_modelo_url.

Además si empezaba a migrar todos los sweepers a observers empezaba a salirme del camino de como le gusta a Rails que se hagan las cosas.

Pero es que resulta que al parecer a Rails no le gusta que se expiren cachés desde un script y el workarround para conseguirlo no es del todo limpio pero se ha conseguido activar los sweepers desde un script para que se disparen al insertar un nuevo modelo en la BD.

El workarround es obra de Daniel Rodriguez Troitiño y aquí podéis revivir la lucha hasta conseguirlo.

Está funcionando para 2.0.1 y no sé si funciona en otras versiones.

require 'action_controller/test_process'
 
ActiveRecord::Base.observers = [MiSweeper]
ActiveRecord::Base.instantiate_observers
 
MiSweeper.instance.controller = ActionController::Base.new
 
tr = ActionController::TestRequest.new
MiSweeper.instance.controller.request = tr
MiSweeper.instance.controller.instance_eval( '@url = ActionController::UrlRewriter.new(tr, {})' )
 
m = MiModelo.new( :nombre => 'el nombre' )
m.save

Vemos que se activa el sweeper como un observer y luego se inicializa con todo lo necesario para que funcione.

Muchas gracias a Daniel que se lo ha tomado como reto personal ;).

Estuve un día volviéndome loco con uno de estos tantos poltergeist que todo lenguaje o framework oculta, en este caso RoR.

Aprovecho para señalar mi opinión de que es imposible conocer un lenguaje/framework en unos pocos meses, por muy listo que seas y por muchos libros que seas capaz de leer en ese periodo. El verdadero conocimiento se esconde después de enfrentarte a un gran número de problemas/errores/bugs/y poltergeist que el lenguaje/framework en cuestión esconde, conocerle como si se tratara de conocer el carácter de una persona con la que convives hasta que entiendes como tratarle y entenderle. Es a lo que aveces nos referimos como la intuición.

Siguiendo con el poltergeist que nos ocupa: se trataba de que al activar la caché de acción en determinados controllers no se me estaban ejecutando los before_filters (aunque curiosamente si se ejecutaban los before_filters del padre ApplicationController  no de mis propios Controllers).

Esto no era muy normal y estaba claro de que algo estaba haciendo mal, pues precisamente una de las peculiaridades de la caché de acción es que siempre ejecuta los filtros, a diferencia de la caché de página que no ejectua nada.

Bueno, después de seguir el sabio consejo: si te estás espesando déjalo para otro día, hoy ya he encontrado lo que ocurría y no es ni más ni menos que el orden en el que se declaran los before_filter y los caches_action.

Yo lo tenía así:

class MiController < ApplicationController
  caches_action :show
  before_filter :ejecutar_antes, :only => [ :show ]
end

Y se solucionó cambiándolo a:

class MiController < ApplicationController
  before_filter :ejecutar_antes, :only => [ :show ]
  caches_action :show
end

Es muy fácil de probar:

class MiController < ApplicationController
  before_filter :X1
  caches_action :show
  before_filter :X2
 
  private
    def X1
      p "XXXXXXXXXXXX1"
    end
 
    def X2
      p "XXXXXXXXXXXX2"
    end
end

Si ejecutas :show una vez que ya está cacheada verás como sólo se ejecuta el primer filtro ‘X1′ y no el ‘X2′.

Si conoces algún sitio dónde se indique el órden en el que hay que hacer estas declaración pega el link en un comentario.

Es lo que tiene ruby.

Llevo un par de horas intentando sacar un Float en formato ‘d.ddd.ddd,dd’. Hay muchas cosas en internet para conseguirlo, pero no todas funcionaban bien, y otras funcionaban demasiado bien, con un montón de opciones.

El caso es que hay un helper del ActionView que tiene la función number_to_currency pero es un cabroncete de helper y no podía acceder desde el modelo. También teníamos la gema Currency pero era un pedazo monstruo para la tontada que yo quería.

Al final la gema Scruffy me ha dado la pista y esto es lo que tengo:

class Float
  def en_euros
    parts = sprintf("%01.#{2}f", self).split('.')
    parts[0].to_s.gsub(/(\d)(?=(\d\d\d)+(?!\d))/, "\\1.") + "," + parts[1].to_s
  end
end

Es un parchecito del Float para poder hacer esto:

>> 1234.566.en_euros
=> "1.234,57"

Este es mi primer apunte seudo-técnico sobre RoR. No es muy profundo, en realidad lo dejo caer aquí como nota mental.

Resulta que cuando instalas el interesantísimo plugin para testear cachés y sweepers: cache-test, éste tiene en su configuración la activación de las cachés en modo test:

ActionController::Base.perform_caching = true

Tanto en el fragment_cache_test.rb como en el page_cache_test.rb.

Hasta ahora esto no me había causado ningún conflicto pues sólo hacía una llamada a una página get/post cacheada en cada test y con la misma llamada comprobaba todo.

Pero con Shoulda se hacen varias llamadas a la misma página en cada llamada se comprueba una cosa y si la página está cacheada hay varias cosas que pueden fallar como éstas:

context "on GET to :show" do
  setup do
    get( :show, :id => '1' )
  end
  should_assign_to :variable1
  should_assign_to :variable2
  should_assign_to :variable3
  should_render_template :show
end

Aquí se hace una llamada get para cada should_ , el primero funcionará pero los posteriores al estar activada la caché fallarán porque la variable o la vista buscada tendrá valor ‘nil‘.

Este no es un problema de Shoulda, simplemente no me había aparecido hasta ahora. Con los tests normales surgirá igual si tienes la caché activada y haces 2 llamadas a la misma página cacheada y esperas encontrar una variable asignada, la segunda en ejecutarse fallará.

Workarround

Lo único que he encontrado por ahora es poner esto en el setup de los tests:

ActionController::Base.fragment_cache_store.reset

Para mí me funciona, para mis tests y para la configuración de mis cachés, puede que a ti no te funcione.

Y lo que si puede ser es que tengas una solución mejor, plis coméntala.