2012-01-31 9 views
7

Hemos tenido un problema en Rails 3.1 cuando lo ejecutamos en modo de desarrollo. Parece que nuestros modelos a veces se vuelven a cargar a mediados de la solicitud, y se establece un nuevo object_id en las clases de nuestro modelo. Que a su vez se traduce en un ActiveRecord :: AssociationTypeMismatchModelos de raíles recargados a mitad de la solicitud que dan como resultado AssociationTypeMismatch

Carácter ActiveRecord :: AssociationTypeMismatch (# 2194222580) era de esperar, tiene carácter (# 2185863000)

Si nos volvemos config.cache_classes = true en development.rb el problema parece ir de distancia, pero no es realista desarrollar así, ya que tendremos que reiniciar constantemente nuestros servidores.

¿Alguien tiene una idea de por qué los modelos se pueden volver a cargar a pedido medio, o si hay una manera de forzar la caché para que dure toda la solicitud?

+1

prueba active_reload gem es caché del modelo, y caduca cuando se realiza cualquier cambio en el modo dev. No sé por qué cambia el tiempo de ejecución. Puedes probar y dejarme saber esta ayuda para la última edición – Amar

+0

Creo que se ve como si funcionara, ahora estamos en los raíles 3.1 y aparentemente active_reload está incluido por defecto en los raíles 3.2. Es un poco difícil de reproducir consistentemente, pero actualizaré esta pregunta si parece que se va en unos días. – aproctor

+0

active_reload no funciona desafortunadamente. Aunque es posible que no lo hayamos configurado correctamente – aproctor

Respuesta

1

Con config.cache_classes = false, cualquier cambio en el modelo provoca una recarga. Esto incluye definir/redefinir una constante definida en/conocida por el modelo.

Tuvimos este problema al usar rspec y ActsAsFu. La redefinición de la clase Fu durante la prueba provocó la recarga de clases relacionadas (incluso relacionadas indirectamente), y obtuvimos el error ActiveRecord :: AssociationTypeMismatch en el objeto relacionado. Nos dimos cuenta de esto porque teníamos pruebas que corrían bien solos, pero fallaban cuando corrían después de otras pruebas. Nuestra solución fue crear clases de Fu con nombres separados para cada configuración y evitar reasignar el nombre de la clase durante la prueba.

Así que mi recomendación es para asegurarse de que no están redefiniendo las constantes conocidas a su clase de caracteres (o se sabe que las clases conocidas de su clase de caracteres, etc.)

+1

Esto parece ser solo una porción diferente en la explicación de @ stuartc. (es decir, parches de mono que redefinen la definición del Modelo, O la definición de modelos relacionados.) Mismo mecanismo ... cambiar un modelo a mediados de fuerzas de prueba carga en cascada. –

0

En el pasado he encontrado que la reapertura (parche de mono) un modelo ActiveRecord realmente recargará toda la clase de arriba a abajo. Intente buscar en su base de código para más de una instancia de class Character.

Cuestiones relacionadas