Life is grand

In Rails you can’t have a column named format in a table as it is a reserved Ruby word. Fair enough. But how then can you handle a database that has a column named that in Rails without using views?

It turns out to be surprisingly logical; modify your Rails model with two new methods. You need a getter and setter so for example:

def dialect
  return self.format
end

def dialect=(value)
  self.format = value
end

Now my model has a method of dialect which gets and sets to format in the database.

In a previous post I showed how to use non-conventional tables in your Rails app. A few days on from that and I have found two ActiveRecord model methods that make it even easier and better; set_primary_key and set_table_name.

This means I don’t even need to use any views as I was previously. Hurrah!

We are getting to a point in our project where we want the different bits to start integrating. One part is Java, another is C++ and the part I am responsible for is Ruby on Rails. All of this runs off of a MySQL 5 database.

The database schema is owned by a C++ guy and while he was willing to modify some of his style to fit Rails conventions I told him not to. To be honest I was worried when I said that. It was a risk thinking that Rails would be able to handle a non-standard database. Not only were primary and join tables named completely differently to Rails conventions but the columns were quite different and the data the one Rails app needed to get at was spread over multiple databases.

About 10 minutes ago I sat back in my creaky chair and sighed a sigh of relief. It all works. Rails handles the non-standard setup just fine.

We first made views of the underlying tables (which is why we are on MySQL 5) to get as close to Rails conventions as we could. It wasn’t perfect though as all our views are prefixed. By default Rails won’t handle that unless I bastardised my model naming which we weren’t going to do. The next trick was to use AustinMoody’s def self.table_name() “mpq.mpqs” end tip to tell Rails what table (actually, views) to use. It also solved the multiple-database problem as you just prefix the table name with the database name.

I then found out about the :join_table option on has_and_belongs_to_many in your models which deals with the join tables.

And that is all it took. I am relieved and impressed with Rails. I get all the good stuff while working on a decidely non-conventional Rails database setup.

And into Jason Hoffman’s talk on systems administration and Rails. Deployment, hosting, power, databases etc.

Strongspace, a Rails app from Joyent, is at 60terabytes. Joyent does TextDrive remember so they know some things. BTW Jason is from Joyent.

Rails is just a small part of your entire system. You need a lot more than just a sorted Rails config to have a well served app.

Virtualisation is the real only way. Xen, VMWare (if you must) or Solaris Zones.

Jason is not enamoured with Linux; “If I could turn Linux into a clever way of saying ‘crashes everyday and doesn’t tell you why’, I would.”

WordPress, half a million users, uses DNS load balancing. Works pretty well.

Joyent chooses:
- Console is Lantronix
- Sun Fire AMD servers, T1000, X4100 etc.
- Opteron 285 and TI SPARC
- 2GB RAM
- Sen Fire X5400 storage
- 500GB SATA discs
- Solaris Nevada OS
- Gigabit with cat6 cables

DTrace is getting Ruby integration so you can write performance tests to find out what exactly is going wrong. DTrace is from Solaris and also ported to Mac OS X in Leopard via XRay in XCode.

Key concepts:
- virtualise
- seperate hardware comp. (db from procesing from storage)
- KISS
- stoichiometry (from chemistry, the practice of adding up. If you can’t just add on another server then you have problems.)
- config management and distributed control
- pool and split i.e. SOA
- Understand what is maximum to understand what should be happening vs. what is (potential)

I’ve asked Jason for the slides to this talk and will post them later.

Excellent talk from Jason.
- DNS and federation

The recent Second Life database breach makes me wonder if websites will want to continue capturing as much info as they can on registration and usage. The practice has been to capture info that is not immediatley useful to the website. Register for Yahoo! Mail or Hotmail etc. and you will be asked many questions that have nothing to do with sending and receiving email. The belief was that all this user info could be of future value.

Now though it may be advantageous to capture less info. Capture just the info you need to use the service and nothing more. That way a breach does less damage.