I want to install a logger so that I can dump all executed SQL of my rails application. Problem is, such logger is associated with AbstractAdapter which initialized very soon under test mode, and thus cannot be set by my initializer code.
I try to put
ActiveRecord::Base.logger = MyCustomLogger.new(STDOUT)
in the end of environment.rb like someone advised but it only works when being run in console environment (kicked by script/console), not when run under test mode.
I wonder if there is any way to config such logger so that I will sure to be invoked under any environment (test, development, production, console)
Creating the logger in config/environment.rb should work. I get SQL logging on standard output when I run unit tests if I put the following line in either config/environment.rb or config/environments/test.rb:
ActiveRecord::Base.logger = Logger.new(STDOUT)
Does your MyCustomLogger class do anything special that causes it to fail during tests? Does it work better if you use Logger.new(STDOUT) instead?
In test/test_helper.rb, before loading config/environment.rb, add:
RAILS_DEFAULT_LOGGER = MyCustomLogger.new(STDOUT)
Relevant code in railties for 2.3 railties/lib/initializer.rb#L35. Not sure how to do it with Rails 3.0 yet. It looks like you need to call Rails#logger=, but I can't find a good spot for it yet.
The best way as far as I can found is to put such code in initializers folder. This way, regardless of the running environment, the logger is always properly installed. And no, on my mac osx Rails 2.3.2 on ruby 1.8.7, if I put ActiveRecord::Base.logger=... inside environment.rb then the logger is not properly installed, since the logger that the Sql Connection used to dump SQL was installed and cached before that.
Related
I would like to use information stored within a the credentials.yml.enc file for a Rails 5.2 app. However, I am struggling to get a command which works perfectly within the console to behave in the same way when inserted into a .rb file.
In the Rails console (on my local development computer) Rails.application.credentials.username returns "my_username"
If I insert this line within a very simple db_backup.rb file as shown below, I get the error:
NameError: uninitialized constant #<Class:#<Backup::Config::DSL:0x00007fb0db941d10>>::Rails
db_backup.rb:
Model.new(:db_backup, 'Description for db_backup') do
##
# PostgreSQL [Database]
#
database PostgreSQL do |db|
db.username = Rails.application.credentials.username
end
end
Please could you explain why I get the different behaviour when using exactly the same line of code in the Rails console / within a .rb file?
The context in which the code is executed is not the same. One is the rails console and the other is the backup command
What happens when you load the Rails console
Launching the rails console means you launch all of the rails stack before executing your code against it. The Rack applications like Sinatra, Rails etc. use the config.ru file as a convention for which file should be run to boot. (You can explore the rabbit hole if you want to have a deep understanding of this)
It means that the vast majority of errors you can encounter when will occur during the console boot, preventing you from executing anything in the console (because boot failed). Instead it will print the stack trace errors for you to figure out what went wrong so you can correct and give it another try.
TL; DR Rails.application.credentials.username in console is executed after all of the Rails stack (models, dependencies, initializers) has loaded in a particular order
What happens when you run the backup command
The backup command is defined here in the bin repo of the backup repo
It goes like this
#!/usr/bin/env ruby
# encoding: utf-8
require File.expand_path("../../lib/backup", __FILE__)
Backup::CLI.start
If you open the required file lib/backup.rb and look around in the Gemfile, you won't fine a place where you have a dependency or a define for the Rails constant.
Thus when you run the backup command and execute your db_backup.rb, the constant Rails called here is ... not defined. Ruby being kind will try to find a nested version of this constant in the current scope which is the Model.new do; end block.
It is still not defined which ruby tells you about with NameError: uninitialized constant #<Class:#<Backup::Config::DSL:0x00007fb0db941d10>>::Rails.
#giglemad gives a great explanation of the issue of class resolution in the execution context (rails console vs. running of the backup ruby file).
To fix your error, just let the code know to use the top-level class lookup (::Rails):
Model.new(:db_backup, 'Description for db_backup') do
##
# PostgreSQL [Database]
#
database PostgreSQL do |db|
db.username = ::Rails.application.credentials.username
end
end
If you're still seeing the missing Rails constant, you'll need to put your script in either a rake task, or require your rails environment.
I ended up resolving this by simply adding the line below to the top of my db_backup.rb:
require './config/environment' # added to enable credentials to be read from Rails environment
I'm using rufus-scheduler for handling cron jobs for a Rails 3.2.x app. The root worker.rb is being fired off by foreman (actually upstart on this particular server) and therefore when it starts off it does not have the Rails context in which to operate. Obviously when I attempt to call logger or Rails.logger it will fail each time.
I'm using log4r as a replacement for the default Rails Logger, which is quite nice, but I am wondering what the proper solution for this problem would be:
1) Do I need to give the script the Rails context at startup (it is simply running rake tasks right now so it ends up getting the Rails environment when the worker script hands off to the rake task and I fear giving the script the Rails env before running the timed task would be overkill since it takes so long to fire up the env)? or
2) Should I just set up log4r as one would do in a non-Rails Ruby script that simply reads in the same log4r.yml config that the Rails app is using and therefore participate in the same log structure?
3) Or some other option I'm not thinking of?
Additionally, I would appreciate either an example or the steps that I should consider with the recommended implementation.
For reference, I followed "How to configure Log4r with Rails 3.0.x?" and I think this could be helpful when integrated with the above: "Properly using Log4r in Ruby Application?"
I think this might be what you're looking for..
Use this within the worker itself, and create a custom named log file
require 'log4r'
logger = Log4r::Logger.new('test')
logger.outputters << Log4r::Outputter.stdout
logger.outputters << Log4r::FileOutputter.new('logtest', :filename => 'logtest.log')
logger.info('started script')
## You're actual worker methods go here
logger.info('finishing')
I am working on some plugin on redmine (project management web application written using Ruby on Rail).
For every change i make to the code of the plugin(say view.html.erb file), i have to restart the redmine(application) server. This is because, it runs on production mode by default.
Will running the application on development mode, solve this problem?
If yes, how can i change its running mode or over-ride this behavior so that classes are loaded per every request (yes this will not be efficient but will be good for development) and changes to the code reflect without restarting the application application server(redmine in this case)
I tried adding this line to environment.rb file
ENV['RAILS_ENV'] ||= 'development'
Also tried answers/comments posted below, but they did'nt solve my problem.
Any working solution would be of great help.
Thank You.
Other Related information:
It uses Rails 2.3.14
and its installed using bitnami stack
For automatic plugin reload on Rails 2.3:
Add config.reload_plugins = true on config/environment.rb. It has to be there, you can't put it on config/environments/development.rb due to the Rails start up steps. You may add if RAILS_ENV = 'development' instead.
config/environment.rb
config.reload_plugins = true
On the plugin's init.rb, add the following line:
init.rb
ActiveSupport::Dependencies.explicitly_unloadable_constants = 'YourPluginModuleName'
That's all. Don't forget to remove it when you're done.
I have some Rake tasks that produce CSV output which I'd like to redirect to a file and open with other tools, but when I run heroku rake foo > foo.csv I get log messages (SQL queries, etc.) in my output.
I've tried Rails.logger = Logger.new('/dev/null') and Rails.logger = Logger.new(STDERR) at the top of the Rake task and while those function as expected locally, they don't have any noticeable effect when I run the task on Heroku.
I'm not too shocked that Heroku would squash STDOUT and STDERR together but it's a mystery to me why sending to /dev/null would not kill the output.
Any help greatly appreciated.
Rails v3.0.0, Heroku bamboo-ree-1.8.7 stack, rake 0.9.2.
I was having the same problem, though I didn't run into it until I changed config/environments/production.rb to have this:
config.logger = Logger.new(STDOUT)
(I did this so that my app would log to the heroku log.)
My fix was this:
config.logger = Logger.new(STDOUT) unless 'rake' == File.basename($0)
From Heroku | Dev Center | Logging:
When a Rails app is pushed, we will automatically install the rails_log_stdout plugin into the application which will redirect logs to stdout.
I think Heroku includes (in the output sent through your git push command) a notification about this (and one other addition: for serving static/public content, if I remember correctly). You may only see the notifications for certain kinds of pushes though (complete slug rebuilds?). I remember seeing it when I recently pushed a new application to a Bamboo/MRI-1.9.2 stack, but I do not think I got the message every time I pushed changes to just the application’s code (maybe adding a new gem to the Gemfile is enough to trigger it?).
Several Rails subsystems keep their own logger binding (independent bindings whose values are often initialized from Rails.logger; reassigning the latter does not change the former):
ActiveRecord::Base.logger
ActionController::Base.logger
ActionMailer::Base.logger
Heroku’s changes probably set a new value for Rails.logger before ActiveRecord is initialized. When ActiveRecord is eventually loaded, it sets its own logger to be the same as Rails.logger (the Heroku/stdout one). When your task runs, it reassigns Rails.logger, but it is too late for this to have any effect on ActiveRecord::Base.logger (the only most likely to be handling the SQL logs).
You probably need to reassign some of these other logger bindings to squelch the logging going to STDOUT. Some other likely locations are listed in rails_log_stdout’s init.rb in the Rails 2 section.
I faced the same problem and found the following to be a more convenient workaround:
Add the following to config/environments/production.rb
config.logger.level = Logger.const_get(ENV['LOG_LEVEL'] ? ENV['LOG_LEVEL'].upcase : 'INFO')
Push to Heroku, then when you run your rake tasks add LOG_LEVEL="fatal" to the end of the command (replace foo and foo.csv with your things):
heroku run rake foo LOG_LEVEL="fatal" > foo.csv
I have log_level set to fatal in the above example, but it can be any of the following: debug|info|warn|error|fatal. In our case, using the highest would mean nothing but the most fatal errors are outputted into the csv file.
Just to help anyone with a "fresh" Rails project pushing to Heroku:
You need a combination of #Matt Burke and #Hengjie's answer:
Add these two lines to config/environments/production.rb:
config.logger = Logger.new(STDOUT)
config.logger.level = Logger.const_get(ENV['LOG_LEVEL'] ? ENV['LOG_LEVEL'].upcase : 'INFO')
This will setup a new STDOUT logger and allow you to easily control the log resolution with the LOG_LEVEL environment variable.
I solved this problem with the following change to production.rb:
if 'rake' == File.basename($0)
ActiveRecord::Base.logger = Logger.new('rake.log', 'daily')
end
I suppose we could ignore the output as well
if 'rake' == File.basename($0)
ActiveRecord::Base.logger = Logger.new('/dev/null')
end
After upgrading to rails 2.3.5 I got things working again and the tests were passing. Then all of a sudden when I run the script/server command it now always runs in Test mode which is seen by a simple > puts RAILS_ENV
I have restarted my machine as well as run the script/server command manually setting the environment via -e, but still have no luck.
Does anyone have any idea what the cause of this would be?
** I should note that even when the RAILS_ENV constant is shows up as "test", the database config that is used is the development.
update
by adding puts RAILS_ENV statements throughout the code I can see that when I add a puts outside the Rails::Initializer.run do |config| block within the environment.rb class that at that point the RAILS_ENV becomes set to "test". Right before the end of the block it is still set to development.
The reason for the environment change was that, without thinking, I loaded the rspec gem in the development.rb file.