Tender Lovemaking

In my last post about Johnson, I said that next time I would talk about the JavaScript parse tree that Johnson provides. Well, I changed my mind. Sorry.

I want to write about a rails plugin that I added to Johnson. Brohuda Katz wrote an ERb type parser in JavaScript, and added it to the (yet to be released) Johnson distribution. With that in mind, and looking at the new template handlers in edge rails, I was able to throw together a rails plugin that allows me to use JavaScript in my rails view code.

Lets get to the code. Here is my controller:

And my EJS view (the file is named index.html.ejs):

The johnson rails plugin puts controller instance variables in to a special javascript variable called "at". The "at" variable is actually a proxy to the controller, lazily fetching instance variables from the controller and importing those objects in to javascript land.

Lets take a look at the plugin, its only a few lines:

When the template gets rendered (the render method), I wrap the controller with an EJS proxy, then compile the template into a javascript function, and call that function. The "at" variable is set to the EJSProxy before executing the template, and all property accessing on the "at" variable is passed along to fetching instance variables from the controller.

Server side javascript coding in rails. Weird, eh?

Despite the recent Ruby webserver speed contests, most of the slowness at my job results from slow (or too many) database queries.

To help keep database queries down, I added a stats to every page that shows the number of queries vs. cache hits, the number of rows returned, and the amount of data transferred from the database. In this screenshot I'm using the "live" environment, 3 cache hits, 169 misses, 577 rows returned, and 458.9k data transferred. Clicking the box hides it, and clicking "Super Hide!" hides the box and sets a cookie so that the box doesn't show up again for a while.

To get this working, first I monkey patch the MysqlAdapter to collect database stats:

Next I patched the QueryCache to keep track of hits and misses:

Then modify ActionController to reset stats for each request:

Just drop all that inside the after_initialize in your development.rb and you'll get the nice stats. After that, just create a partial that displays the stats and include the partial at the bottom of your layout. Our partial looks like this:

It's a little work, but it helps keep my mind on reducing the queries. With enough work, one of these days the speed of the webserver will matter to me. Thanks to Adam Doppelt for the basis of this monkey patch. Any bugs are mine, not his!

I've just released "Trigger Happy", a rails plugin that adds support for triggers in your Active Record Migrations. To install the plugin just do this:

To add a trigger do this:

To drop a trigger do this:

It only supports mysql for now, but I plan on having other database supported in the future.

I've been trying to create an audit log for a few (12) tables, and unfortunately ActiveRecord seems to be falling flat for what I want to do. First I'll describe whats out there already to do this, then I'll talk about what I had to do.

There are a couple nice plugins out there for helping you keep track of changes to your records. The first one is actsasversioned. actsasversioned will copy your record to a version table whenever there is an insert or update, then increase a version number in the original table. It also automatically adds a list of versions to your original model, and lets you revert to any particular version. This is great, and almost exactly what I needed. I didn't really need the ability to revert to a version, but that just seemed like gravy on top. The only problem with actsasversioned comes in when you try to keep track of changes to habtm relationships. But this is where the second plugin comes in to play.

The second plugin is called actsasversionedassociation. This plugin will help you keep track of changes to your relationships. actsasversionedassociation is built on top of actsasversioned. They way it works is by setting the owner model to actsasversioned, then when any associations are updated, it writes a new version of the owner model, then writes the associations to a associations version table. So if you were to have an Article model that has and belongs to many Documents, you would need 5 tables to represent that:

1. articles
2. articles_versions
3. documents
4. articles_documents
5. articles_documents_versions

If the association changes, a record is written to articles (to increase the version number), articlesversions, articlesdocuments, and articlesdocumentsversions. But what happens if Article has 10 versioned habtm relationships, and just one of those relationships changes? Then a record will get written to every habtm version table for just one change. Thats 12 writes for a change to just one relationship. That will not scale....

Fortunately I don't care about reverting to a previous version. All I care about is what changed, and when. So my favorite solution for this problem is to add triggers to the tables that may change. That way I only get one extra write when a relationship changes. Just copy the row to another table with a timestamp and an action.

But what about has_many :through?

hasmany :through allows you to put a model on top of the join table. Then I could just drop actsasversioned on top of that model and be done. I would have used this solution except that I ran in to a bug. hasmany :through does not support all of the same array manipulation that habtm does. For example, you can append (<<) to hasmany :through and habtm, but the clear method does not work the same way on hasmany :through. Also, has_many :through does not set an attribute= method like habtm does.