¿Puedo cambiar config.cache_classes programáticamente en Rails 3?

Question

Tengo algunas pruebas de cliente de iPhone que se ejecutan en mi servidor de rails de desarrollo. Todo el paquete ejecuta un orden de magnitud más rápido si activo el almacenamiento en caché de clases en la configuración de Rails. Por otro lado, eso ralentiza el desarrollo cuando en realidad no estoy ejecutando las pruebas.

Quiero que el banco de pruebas active una acción al principio para activar el almacenamiento en caché de clases y otra acción al final para desactivar nuevamente el almacenamiento en caché de clases.

¿Esto es posible? ¿Si es así, cómo?

Answer 1

No creo que hacer lo que sugiera funcionará.

Pero sugiero que puede estar buscando la solución incorrecta.

Si lo que desea es acceder a su base de datos de desarrollo desde su prueba de iphone, , ¿por qué no agregar un nuevo entorno?

Añadir un nuevo archivo de configuración/ambientes/iphone_dev.rb

require File.dirname(__FILE__)+"/development.rb" 
config.cache_classes = true 

Y en su database.yml (o mongoid.yml o lo que sea)

iphone_dev: 
    host: localhost 
    database: my_app_development 

No hay razón por la que no puede base de datos ser el mismo

Ahora acaba de ejecutar rails server -eiphone_dev -p3001

Usted debe tiene un servidor, casi el mismo que su servidor de desarrollo, pero se ejecuta en un puerto diferente, con el almacenamiento en caché habilitado.

Answer 2

No sin algunas graves piratas informáticas. Rails se toma un montón de molestias para asegurarse de que sus archivos se vuelvan a cargar en cada solicitud (cuando cache_classes=false). El valor de la variable de configuración cache_classes es utilizado por inicializadores en varios lugares no menos importante de los cuales es:

• usando require para cargar archivos de rubí cuando cache_classes es true (lo que significa que ya no son recargables)
• establecer devoluciones de llamada del despachador de reaload la aplicación en cada petición cuando cache_classes es false

usted tiene acceso al valor de la variable cache_classes, e incluso se puede cambiarlo si lo desea:

Rails.configuration.cache_classes = true 

embargo, esto no tendrá ningún efecto en la instancia carriles de rodadura como los inicializadores donde se utiliza ese valor sólo se ejecutan una vez cuando la aplicación se inicia rieles.

Lo que esto significa es que, a menos que esté preparado para invertir un poco de tiempo y esfuerzos de piratería no puede evitar el reinicio de su servidor. Entonces, lo que debe observar es controlar este proceso de reinicio a través de su banco de pruebas.

Por ejemplo, puede intentar reiniciar rails from within rails.Esto le permitiría definir una acción que su banco de pruebas puede alcanzar justo antes de comenzar a ejecutar (para reiniciar el servidor en el modo correcto) y otra acción que el servidor puede ejecutar después de que todas las pruebas hayan finalizado, para reiniciar todo con cache_classes establecer a lo que solía ser Usted controlaría el valor de las clases de caché mediante una variable de entorno like this post suggests.

Todavía requerirá un poco de trabajo configurar todo esto y lograr que se mantenga unido, pero esta es probablemente la mejor opción si quiere una solución "auto-mágica".