Sake and Database Shells

If you haven’t installed Sake yet, stop whatever it is you’re doing and get it running on your system.

Ok, with that done you’ll probably want some sake tasks to actually make this new tool useful. Below is an updated version of one my favorite tasks.

desc 'Launches the database shell using the values defined in config/database.yml'
task 'db:shell' => [ 'environment' ] do
  config = ActiveRecord::Base.configurations[(RAILS_ENV or "development")]
  command = ""
  case config["adapter"]
  when "mysql" then
    command << "mysql "
    command << "--host=#{(config["host"] or "localhost")} "
    command << "--port=#{(config["port"] or 3306)} "
    command << "--user=#{(config["username"] or "root")} "
    command << "--password=#{(config["password"] or "")} "
    command << config["database"])
  when "postgresql" then
    command << "export PGPASSWORD=#{config["password"]} && " unless config["password"].blank?
    command << "psql "
    command << "-h #{(config["host"])} " unless config ["host"].blank?
    command << "-p #{(config["port"])} ") unless config ["port"].blank?
    command << "-U #{(config["username"])} " unless config["username"].blank?
    command << config["database"]
  when "sqlite3"
    command << "sqlite3 #{config["database"]}"
  else
    command << "echo Unsupported database adapter: #{config["adapter"]}"
  end
  system(command)
end

With the above task you be in any RAILS_ROOT and type sake db:shell and be automatically placed into the appropriate database shell with your username/password/host/port setup already. You can even do sake db:shell RAILS_ENV=production.

I can’t take credit for this task, in fact I originally found it on the Sake Bomb blog post by Err The Blog. The link found in the comments on that page no longer works, but some googling turned up the source code elsewhere. I’ve added Postgres and sqlite3 to the mix as it only supported MySQL originally. If you know who the original author is please let me know as I would like to credit them.

Rails is great, but…

Don’t get me wrong, I really enjoy working with Rails, but every now and then something about it bothers me. Josh Susser of has_many :through recently blogged about the sometimes differing functionality of size, length and count in ActiveRecord.

Did you catch that, _differing_. When using the count method on association collections ActiveRecord responds differently based on pervious usage. When you’re working alone or on small code bases this might not be a big deal, you might never run into it, maybe you’d even be able to use it to your advantage. The same could be said for larger projects or working with multiple developers, but it’s far more likely to cause a hard to track down bug.

I understand Rails is an open source project controlled by people with their own interests at mind, so please don’t read this as an attack against them or the project in general. I am not the first person to mention these kind of anomalies in the framework, and probably not the first person to have this thought, but would it make sense to fork the project?

I’m not sure it’s worth forking Rails to make it more “enterprisey” (read: consistent). It would be great to have a stable platform, maybe it would receive better acceptance in the office (ie: maybe my python coworkers wouldn’t pick on it). My biggest concern is that removing all these idiosyncrasies will make it impossible to port future creativity from the original authors. Again, that wouldn’t be the end of the world if such a project could attract new development, but I just don’t see that happening. Any thoughts?

I think I’m going to keep a little list going of the things that irk me about Rails. Each time I come across one Merb gets more and more tempting. I really want to dig into Merb, I’ve yet to get do anything more complex than a few basic tutorials, I just need a project…

Rambling one post at a time