
August 30th, 2007 by

Jack
In our applications, many of our controllers should only be interacted with via AJAX. This is easy enough to enforce in a controller, using the special verification filter:
class PostController < ApplicationController
verify :xhr => true, :render => { :text => "This action must be accessed using XMLHttpRequest." }
end
However, it took me a little while to figure out how to test this appropriately. The following functional test for the above controller will fail:
def test_edit
post :edit, :id => 1
assert_kind_of Post, assigns("post")
end
In order to simulate an AJAX request, you need to use the xhr method instead of the post method:
def test_edit
xhr :post, :edit, :id => 1
assert_kind_of Post, assigns("post")
end
Unfortunately, this technique doesn’t seem to be mentioned in the Guide to Testing the Rails.
Posted in ruby on rails |
1 Comment »

March 8th, 2007 by

Forrest
To use active record with another database, simply create a new model and name it whatever you would like. For example, If your current Rails App is set up to use the database example_development, and you need table customers from another database, create a new model and name it other_customer.rb like so;
class OtherCustomer< ActiveRecord::Base
set_table_name "customers"
OtherCustomer.establish_connection(
:adapter => “mysql”,
:host => “localhost”,
:username => “root”,
:password => “”,
:database => “other_db_development”
)
end
The tricky thing here is if there happens to be a table already named customers in your current Application, it will start using this new configuration for any call of Customer. The trick to this is to add the same establish connection in your current Customer model. So that customer.rb now reads;
class Customer< ActiveRecord::Base
Customer.establish_connection(
:adapter => “mysql”,
:host => “localhost”,
:username => “root”,
:password => “”,
:database => “example_development”
)
end
There, now any call of Customer or Customer.* will pull from example_development whereas any call of OtherCustomer or OtherCustomer.* will pull from other_db_development. Any other model will continue to query example_development.
Posted in ruby on rails |
No Comments »

November 21st, 2006 by

Jack
If you use the Active Record Store as your Session Store, keep in mind that it is inserting rows into a database table for each new HTTP session. Over time, this can accumulate a lot of sessions (one of our products had 800,000 after a few months), most of which are stale.
Luckily, we quickly found the answer at RealityForge : a quick and clean class run by script/runner from a cronjob.
However, our application was using the Bundled Resource plugin which copies static file bundles during each application initalization, which was causing our SessionCleaner to die. This was a pretty easy fix:
RAILS_BUNDLES=no /var/www/application/current/script/runner -e production "SessionCleaner.remove_stale_sessions"
Posted in ruby on rails |
No Comments »

October 24th, 2006 by

Jack
A reiteration from Schwuk - log rotation in Ruby on Rails is as simple as an extra line in your config/environment.rb file:
RAILS_DEFAULT_LOGGER = Logger.new("#{RAILS_ROOT}/log/#{RAILS_ENV}.log", 20, 10.megabyte)
I put this line right BEFORE the Rails::Initializer.The above line will automatically rotate your logs when they hit 10 megabytes, and it will keep the 20 most recent logfiles.
The details of this mechanism can be found in the Logger standard Ruby library. Specifically:
- Create a logger which ages logfile once it reaches a certain size. Leave 10 “old log files” and each file is about 1,024,000 bytes.
logger = Logger.new('foo.log', 10, 1024000)
- Create a logger which ages logfile daily/weekly/monthly.
logger = Logger.new('foo.log', 'daily')
logger = Logger.new('foo.log', 'weekly')
logger = Logger.new('foo.log', 'monthly')
Posted in ruby on rails |
2 Comments »