In order to do the same thing under Rails 3, I had to make a few adjustments. First of all, you need the rails3_acts_as_paranoid gem, which is a total rewrite of acts_as_paranoid for rails 3. Add these lines to your Gemfile:

gem 'rails3_acts_as_paranoid'
gem 'acts_as_versioned'

Then put a file in config/initializers with these contents:

module ActiveRecord
  module Acts
    module Versioned
      def acts_as_paranoid_versioned(options = {})
        acts_as_paranoid
        acts_as_versioned options

        # Override the destroy method. We want deleted records to end up in the versioned table,
        # not in the non-versioned table.
        self.class_eval do
          def destroy()
            with_transaction_returning_status do
              run_callbacks :destroy do
                # call the acts_as_paranoid delete function
                self.class.delete_all(:id => self.id)

                # get the 'deleted' object
                tmp = self.class.unscoped.find(id)

                # run it through the equivalent of acts_as_versioned's
                # save_version(). We used to call that function but it is a
                # noop when @saving_version is not set. That only gets done in
                # a protected function set_new_version(). Easier to just
                # replicate the meat of the save_version() function here.
                rev = tmp.class.versioned_class.new
                clone_versioned_model(tmp, rev)
                rev.send("#{tmp.class.version_column}=", send(tmp.class.version_column))
                rev.send("#{tmp.class.versioned_foreign_key}=", id)
                rev.save

                # and finally really destroy the original
                self.class.delete_all!(:id => self.id)
              end
            end
          end
        end

        # protect the versioned model
        self.versioned_class.class_eval do
          def self.delete_all(conditions = nil); return; end
        end
      end
    end
  end
end

I wonder if there is a more elegant way to achieve this…

Note: code updated at 2011-05-28 to make sure :dependent => :destroy on has_many associations does the right thing.

check process mongrel_8010 with pidfile /path/to/current/log/mongrel.8010.pid
  start program = "/usr/bin/mongrel_rails cluster::start -C /path/to/current/config/mongrel_cluster.yml --clean --only 8010"
  stop program = "/usr/bin/mongrel_rails cluster::stop -C /path/to/current/config/mongrel_cluster.yml --clean --only 8010"

  if failed host 127.0.0.1 port 8010
    with timeout 10 seconds
    then restart

  if totalmem > 128 Mb then restart
  if cpu is greater than 60% for 2 cycles then alert
  if 3 restarts within 5 cycles then timeout
  group mongrel

The start/stop commands work perfectly from the command line, but somehow not when monit’s calling them. Sure enough, you find this in the mongrel.8010.log file:

/usr/lib/ruby/gems/1.8/gems/rubyforge-1.0.3/lib/rubyforge.rb:15:in `expand_path': couldn't find HOME environment -- expanding `~' (ArgumentError)

The line in question is

  HOME        = ENV["HOME"] || ENV["HOMEPATH"] || File::expand_path("~")

Monit does not set a HOME environment variable, nor HOMEPATH.

The documentation for File::expand_path says:

Converts a pathname to an absolute pathname. Relative paths are referenced from the 
current working directory of the process unless dir_string is given, in which case it 
will be used as the starting point. The given pathname may start with a ``~’’, which 
expands to the process owner‘s home directory (the environment variable HOME must 
be set correctly). ``~user’’ expands to the named user‘s home directory. 

Ouch. So if HOME is not set, File::expand_path(“~”) is guaranteed to fail. That’s a bug in the rubyforge gem I think.

I worked around this by setting ENV["HOME"] to a fallback value before the

require 'rubygems'

line in /usr/bin/mongrel_rails.

I filed a bug. It took me a while to figure out that the rubyforge gem is part of the codeforpeople project on rubyforge.

  start program = "/usr/bin/mongrel_rails cluster::start -C path-to-mongrel_cluster.yml --clean --only PORT"
  stop program = "/usr/bin/mongrel_rails cluster::stop -C path-to-mongrel_cluster.yml --clean --only PORT"

I have the latest mongrel_cluster gem installed (1.0.5), and yet mongrel_rails kept throwing errors about –clean and –only:

invalid option: --clean for command 'cluster::start'
invalid option: --only for command 'cluster::start'

Turns out I had an older mongrel_cluster gem installed as well:

$ sudo gem cleanup mongrel_cluster
Cleaning up installed gems...
:0:Warning: Gem::SourceIndex#search support for Regexp patterns is deprecated
Attempting to uninstall mongrel_cluster-0.2.1
Successfully uninstalled mongrel_cluster-0.2.1
Clean Up Complete

After running gem cleanup, the mongrel_rails commands above started working.

This kind of code behaviour irks me – it’s not intuitive. It does not help that ‘gem list’ suggests that having multiple versions of a gem installed is not a problem – and it usually is not. I guess the mongrel_cluster gem is an exception. File this one under ‘good to know’…

However, it does not change the environment variables from the user it was started as. In particular, ENV["USER"] and ENV["HOME"] remain set to, say, ‘root’ and ‘/root’ respectively.

If you then try to use the ruby gpgme wrappers you’ll run into strange errors. No Ruby exceptions are triggered, but things go wrong in the gpgme_n C wrapper code. From there, gpg is called as the mongrel user, but with environment variables pointing to root’s home directory. Ouch.

Of course you won’t see the problem in development mode (because typically there you run mongrel as the user you are working as).

The solution is simple: force those two variables in your environment.rb file to the correct values for the user you are running as, but not for development mode.

The 2 plugins don’t work together all that well without some modification, as described by Flinn Mueller here.

His solution solves part of the problem – deleting a record no longer deletes the versioned history of the record. But it still leaves the original record in the main table, with a deleted_at timestamp. I want to move that ‘deleted’ record into the versions table, with accurate deleted_at timestamp.

Here’s how I modified Flinn’s code to do that:

module ActiveRecord
  module Acts
    module Versioned
      module ClassMethods
        def acts_as_paranoid_versioned(options = {})
          acts_as_paranoid
          acts_as_versioned options

          # Override the destroy method. We want deleted records to end up in the versioned table,
          # not in the non-versioned table.
          self.class_eval do
            def destroy()
              transaction {
                destroy_with_callbacks                 # call the acts_as_paranoid delete function
                tmp = self.class.find_with_deleted(id) # get the 'deleted' object
                tmp.save_version()                     # run it through acts_as_versioned's save_version()
                tmp.destroy_without_callbacks!         # and finally really destroy the original
              }
            end
          end

          # protect the versioned model
          self.versioned_class.class_eval do
            def self.delete_all(conditions = nil); return; end
          end
        end
      end
    end
  end
end

This code goes in config/environment.rb. As you can see it’s a bit of a hack, but it works. If you have suggestions to do this more elegantly, by all means leave a comment.

I think it’s time someone merges acts_as_paranoid into acts_as_versioned. Maybe I’ll look at that one day when I have more time – for now this will do.