Esto es una pregunta chorra, asi que no os riais demasiado 
¿Porque usar el fichero database.yml y no incluir un fichero rb normal?
Si a cada peticion, rails tiene que leer del disco duro ese fichero y
“parsearlo” para sacar las configuraciones, no seria mas rapido que
fuese un fichero normal que es incluido como cualquier otro fichero rb?
Tranquilo, que el database.yml no se lee a cada petición 
On Fri, Mar 14, 2008 at 4:33 PM, Javier MartÃnez [email protected]
wrote:
–
Ernesto Jiménez
Software Engineer Leader
Negonation
(34) 620 475 382
[email protected]
El Viernes, 14 de Marzo de 2008, Javier Martínez
escribió:> Esto es una pregunta chorra, asi que no os riais demasiado 
¿Porque usar el fichero database.yml y no incluir un fichero rb normal?
Si a cada peticion, rails tiene que leer del disco duro ese fichero y
“parsearlo” para sacar las configuraciones, no seria mas rapido que
fuese un fichero normal que es incluido como cualquier otro fichero rb?
Inicia el servidor web y navega la página (que muestre datos de tablas y
tal).
Ahora borra (o mueve a otro sitio) el database.yml y sigue navegando.
¿Falla?
Estás haciendo las pruebas en modo development o production?
El Sábado, 15 de Marzo de 2008, Javier MartÃnez Fernández escribió:
Nada de eso, era una pregunta generica.
Pero veo que Rails de alguna manera “guarda” ese archivo la ¿primera
vez que se inicia el servidor?
Si es asi, como puede hacer eso?
ES una buena pregunta, ¿depende del servidor web? porque por ejemplo
apache no
es un servidor de aplicaciones, es un mero servidor web. Si se llama a
una
URL apache lanza lo que corresponda pero no “precarga” datos de las
distintas
aplicaciones/webs que contiene.
Nada de eso, era una pregunta generica.
Pero veo que Rails de alguna manera “guarda” ese archivo la ¿primera
vez que se inicia el servidor?
Si es asi, como puede hacer eso?
Gracias por las respuestas.
El 15/03/2008, a las 12:50, Ernesto Jiménez escribió:
Veamos, toda la configuración de rails se hace al iniciar el servidor
de aplicaciones.
De eso (incluido leer el database.yml) se encarga Rails::Initializer.
Si os fijáis en en config/environment.rb tenéis:
Rails::Initializer.run do |config|
#…
end
Es en esa parte del código cuando se carga el database.yml
El environment.rb se ejecuta al arrancar el servidor para cargar todas
las clases básicas de Rails, las configuraciones, los plugins…
No se ejecuta en cada petición.
2008/3/15 Iñaki Baz C. [email protected]:
aplicaciones/webs que contiene.
simplelogica.net
–
Ernesto Jiménez
Software Engineer Leader
Negonation
(34) 620 475 382
[email protected]
El Sábado, 15 de Marzo de 2008, Ernesto Jiménez escribió:
Es en esa parte del código cuando se carga el database.yml
El environment.rb se ejecuta al arrancar el servidor para cargar todas
las clases básicas de Rails, las configuraciones, los plugins…No se ejecuta en cada petición.
Entonces debe haber necesariamente alguna comunicación entre Apache y
cada
aplicación Rails cuando se inicia el Apache, o sea, no es como una mera
aplicación PHP en la que se ejecuta TODO a cada petición y ya está.
Lo que pasa es que sólo una vez puse un Rails con Apache y ni recuerdo
qué
hice XD
Saludos y gracias por la explicación.
buenas,
Entonces debe haber necesariamente alguna comunicación entre Apache y cada
aplicación Rails cuando se inicia el Apache, o sea, no es como una mera
aplicación PHP en la que se ejecuta TODO a cada petición y ya está.
En realidad el apache “no hace nada”. Apache simplemente se configura
para que sirva el contenido estático, y todo lo que no sea un fichero
plano en disco se lo pasa al servidor de aplicaciones (o al dispatcher
de cgi/fastcgi). Apache no sabe nada de Ruby o de tu aplicación, sólo
sabe que si un fichero estático no lo encuentra, manda la petición a un
proceso que le devuelve un response que Apache devuelve al cliente (en
ese momento apache puede usar módulos como mod_deflate, por ejemplo). La
gracia de tener Apache es que es muy rápido para el contenido estático y
que además con el módulo mod_balancer te sirve de balanceador entre tus
diferentes servidores de aplicaciones Rails.
Es el servidor, por ejemplo mongrel, el que se ocupa de toda la gestión
de la aplicación. Básicamente lo que hace es inicializar rails
(ejecutando el script boot.rb) al arrancar. Luego se queda escuchando en
un puerto, y cada vez que recibe una petición desde apache, la procesa
usando ActionController::Dispatcher, y devuelve a Apache el resultado.
Y por no ser injustos, si PHP lo configuras con FastCGI también puedes
conseguir que toda la inicialización se ejecute una sola vez (por
ejemplo las conexiones contra la base de datos) y no se ejecuta siempre
desde cero en ese caso. Es lo mismo que hace FastCGI cuando lo usas con
Rails.
Saludos,
javier ramÃrez
Una cosita más que he aprendido, gracias Javier
El dÃa 15/03/08, Iñaki Baz C. [email protected] escribió:
El Sábado, 15 de Marzo de 2008, javier ramirez escribió:
sabe que si un fichero estático no lo encuentra, manda la petición a un
usando ActionController::Dispatcher, y devuelve a Apache el resultado.Y por no ser injustos, si PHP lo configuras con FastCGI también puedes
conseguir que toda la inicialización se ejecute una sola vez (por
ejemplo las conexiones contra la base de datos) y no se ejecuta siempre
desde cero en ese caso. Es lo mismo que hace FastCGI cuando lo usas con
Rails.
Gloriosa aclaración
Gracias.