Lo de ayer se solucionó tirando a la basura el lightty, y poniendo mongrel sobre apache. Además, tuve que poner un parámetro adicional en el database.yml: socket = /tmp/mysql.sock Por alguna causa, cuando ejecutaba la aplicación desde el web server, lo buscaba en: /tmp/mysql.sock, pero cuando lo ejecutaba desde script/console, lo buscaba en otro camino más largo, que realmente no recuerdo. Poniendo socket = /tmp/mysql.sock se fuerza al mismo camino en todos los casos. Aclaro también que en /etc/my.cnf, estaba seteado dicho path.
Por otro lado yo había manoseado el environment.rb. Había hecho lo siguiente: # Be sure to restart your web server when you modify this file. # Uncomment below to force Rails into production mode when # you don't control web/app server and can't set it the proper way # ENV['RAILS_ENV'] ||= 'production' # My own variables here (ESTO ES MIO) # ENV['HOST'] Could be: gertrudix, playground, VPS ENV['HOST'] ||= 'VPS' # Specifies gem version of Rails to use when vendor/rails is not present RAILS_GEM_VERSION = '1.1.6' if (ENV['HOST'] == 'florida') || (ENV['HOST'] == 'oficina') || (ENV['HOST'] == 'playground') RAILS_GEM_VERSION = '1.2.3' if (ENV['HOST'] == 'VPS') Como ven el string: RAILS_GEM_VERSION está dos veces. Al principio, me pareció que funcionaba, puesto que lograba hacerlo funcionar en dos ambientes diferentes, uno con la versión 1.1.6 y otro con la versión 1.2.3. El problema empezó a surgir cuando intenté ejecutar /script/console La cuestión que estar manoseando de esta forma el environment.rb "mama" al boot.rb, puesto que (échenle un viztaso al código) busca ese string para saber qué RAILS_GEM_VERSION está activa. Una lástima, porque pensé que con un código así podía hacerlo más compatible con diferentes versions de rails gem. Pero no, mejor no manosear más allá de lo estándar el enviroment.rb
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
