Sketchpad – Dan Sketcher’s personal blog

I am working with a legacy database. Usually, the built in rails stuff for table prefixing and primary key changes is enough. Sometimes, it’s not.

I had a problem with a join table that has Foreign Key names that are tablename_id, but the tables they reference is tablename_id as well. The has_and_belongs_to_many method DID NOT like it at all. Added to this is that there are attributes in the join table (is_primary) that I need to use. I considered (and discussed with the Java devs) the option of making the join table have an ID and making it a model, but there was potential for breakage and I like to tred very carefully around the existing app and making changes.

So, a bit of time on Google later, and I came across Nic Williams’ Composite Primary Key plugin. Oh man, it works a treat. I created the model for the join table, specified the primary keys, and went as normal!

Beautiful.

Setting up my new computer now that I am settled in in London was turning out to be a right pain. I had ruby, rails, and postgresql installed, but my application was not starting.

I was getting the following error:

=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
Exiting
/opt/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/commands/servers/mongrel.rb:15: warning: already initialized constant OPTIONS
/opt/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/commands/servers/mongrel.rb:18: undefined method `options' for []:Array (NoMethodError)
        from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:32:in `gem_original_require'
        from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:32:in `require'
        from /opt/local/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:495:in `require'
        from /opt/local/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:342:in `new_constants_in'
        from /opt/local/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:495:in `require'
        from /opt/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/commands/server.rb:39
        from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
        from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `require'
        from /opt/local/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:495:in `require'
        from /opt/local/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:342:in `new_constants_in'
        from /opt/local/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:495:in `require'
        from script/server:3

and lots more similar ones. I tried uninstalling Mongrel, reactivating old versions of rails, and so on. Nothing worked. A fresh rails application started ok though Searching online revealed nothing either, until I came upon a post about a gem not working on win32, and the solution was to remove that gem.

Ahhhhh.

I was missing gems. I installed every one that I had on my lappy, and everthing was cheerful again. Strange that the error message (even under webrick) did not report the problem clearly. In any case, problem resolved.

I am in the middle of an update to my PeopleHub application and I started getting a weird error in my tests (yay for tests): ActiveRecord::RecordNotSaved

Part of the update was changing my before_save code to only do an expensive recalculation when it was required, and after doing so, setting the flag that it used to false (so that next time it didn’t do the expensive recalc). The code looked like this:

def before_save
  if self.do_update
    if x
      write_attribute("the_field", the_field_data)
      self.do_update = false
    elsif y
    end
  end
end

(please excuse the formatting. looks like my css needs attention)

So the end result of this is that in certain cases, the update is never done again. However, note that I am setting self.do_update = false at the end of the block. For those who remember their Ruby fundamentals (d’oh) they will know that if that line is the last that is evaluated in the block, it will return FALSE. As the docs say:

If a before_* callback returns false, all the later callbacks and the associated action are cancelled. If an after_* callback returns false, all the later callbacks are cancelled.

Whoops. Thanks to Rick Olsen (http://threebit.net/mail-archive/rails/msg38644.html) for the help

EDIT 2007-06-05: An updated version of this is up here…

After my hiatus on posting it seems appropriate to get back into the meaty stuff…

Ever since I started using Debian (instead of FreeBSD) I’ve been having weird problems with my rails dispatch.fcgi processes multiplying in the night. Nothing shows up in the logs, but I spawn 2 externally of Lighttpd, and in the morning i’ve got 6 of the little blighters. Of course, at 20-30 meg a pop, the poor little Xen VPS isn’t too happy about that, so I have a nightly job that kills them all and restarts them. And then, 12 hours later, 4 more than I asked for are there. It seems to be a load issue, but I digress.

So ever since I noticed that I’ve been wanting to use Mongrel to run my Rails apps. For those not familiar with mongrel, it’s a Tomcat-style application host for rails apps that avoids (huzzah) the FCGI palaver that we ordinarily have to deal with. The problem was that according to mongrel, a USR2 signal should fully restart the daemon, and it does, but it’s a tiny little bit funny in a way that makes it totally painful to use with Capistrano for automated deployment.

You see, on restart, it doesn’t re-evaluate what the ./current symlink is pointing to. So when it’s restarted over a ./current that points to ./releases/2006xxxxxxxxx1 that’s fine, but on a redeployment through Cap when this symlink is repointed to ./releases/2006xxxxxxxxx2, the mongrel instance still points to ./releases/2006xxxxxxxxx1

So that’s not so good. Btw, Zed, you’re an awesome coder and I in no way mean you disrespect here. I’m just telling the problem I faced.

Along comes mongrel_cluster. Totally fixed the issue for me, and here’s how.

1. Install mongrel_cluster, and then (in ./current) run “mongrel_rails cluster::configure”

2. open the new ./config/mongrel_cluster.yml and edit the line that starts with “cwd:” like so:

• change “cwd: /path/to/app/releases/2006xxxxxxxxx1″ to “cwd: /path/to/app/current”
• change the port to the first one you want for this cluster, and select how many you want (defauts to 2 which should be ‘enough’ for most cases)
• change from “development” to “production”

3. Add the following tasks to your capistrano deploy.rb file

desc “The spinner task is used by :cold_deploy to start the application up”
task :spinner, :roles => :app do
send(run_method, “cd #{deploy_to}/#{current_dir} && mongrel_rails cluster::start”)
end

desc “Restart the mongrel cluster”
task :restart, :roles => :app do
send(run_method, “cd #{deploy_to}/#{current_dir} && mongrel_rails cluster::restart”)
end

4. Rejoice!

5. Before you do anything else, add to your crontab an @restart task to start the mongrel instances when your server comes up! Very important!

Now “rake remote:cold_deploy” and “rake remote:deploy” work for the mongrel cluster! I used the instructions on the mongrel site on how to integrate with lighttpd at http://mongrel.rubyforge.org/docs/lighttpd.html but there are equally good Apache 2.2 docs out there (why Apache 2.2 isn’t available for Debian is anoher question entirely…)
Much kudos and thanks to Zed Shaw for the excellent mongrel server and to Bradley Taylor for mongrel_cluster. Oh, and Jamis Buck for Capistrano!