Java The Hutt

For those of you out there that eventually get into a real world application on a domain this tip is for you. When you deploy your rails app and start having sessions created you probably won't notice right away that

http://www.yourdomain.com and http://yourdomain.com

are two different sites to rails and if you visit each of them you will get a different cookie and thus a different session for each of those two URLs.

This is easily rectified by setting the session domain in one of your environment configuration files, probably production.rb.

ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS.update(:session_domain => '.yourdomain.com')

This entry will ensure that visitors to your site will have one session for both the www and non-www variant of your site. But be careful, when you try and run in production on any other machine you need to either comment this change out or make the appropriate change to the setting, otherwise your site will inexplicably stop working and you'll wonder "WTF is going on here?" like I did :-)

I started using rails at version .13.1 which was the very last release before database migrations were introduced. For those that don't know rails' migration mechanism is helpful when making incremental changes to your database. You may need to do one or more of the following:

1. Add/remove a column to a table
   
2. Change an existing column's definition
   
3. Modify your data.
   

It's fairly simple to get started. Jamis Buck (The creator of migrations) has a tutorial here

When it works migrations is a handy tool. When it doesn't it can be a little frustrating because it doesn't do a good job of telling you what's wrong. I have 3 specific scenarios where anyone using rails is probably likely to stumble upon these:

1. In the command "rake migrate VERSION=1", "VERSION" is case sensitive. That's right version=1 won't work but you won't get an error message indicating anything close to indicating that. In fact if I remember correctly (it's been awhile since I first stumbled on this problem) you don't get any feedback other than the command prompt returning to you.
   
2. During one development cycle I typed "rake migrate" and received:
   

   
   rake aborted!
   cannot convert nil into String
   

   
   This turned out to be that the RAILS_ENV variable wasn't set. passing that in on the command to migrate fixed the problem.
   
3. Another time I typed "rake migrate" and received:
   

   
   You have a nil object when you didn't expect it!
   You might have expected an instance of Array.
   The error occured while evaluating nil.[]
   

   
   This one was because I had tried to create a column and specified a datatype that isn't supported natively in AR and migrations.
   

None of these are dealbreakers in and of themselves but it's really frustrating when something breaks and there's no stacktrace to be seen anywhere. If we can't get decent error messages can we at least get a stacktrace?