Usually one of the first things I read about on how to speed up ActiveRecord is to index my columns to speed up the lookup of items. “Of course!” But could indexing too much be harmful?
Essentially, if your column is an enum, then indexing it could actually cause MySQL to do more work. Why? Because the data set is so large, the MySQL ends up doing a full scan. So things like keeping track if something is active (1 or 0) then you can expect indexing to hurt.
So how does this effect ActiveRecord? Well, if you’re keeping track of whether a user is active or not you would not want to index that column alone. Nor would you want to index a type column if you were using single table inheritance, again, because there isn’t a lot of variance in the type.
So make sure that you index the right things, like IDs and leave the enum-like columns alone.
RailsForge is hosting a survey to see what you, the Rails community, would like in a site for rails gems and plugin management.
So if you have some free time, please take the survey to help this project turn into something that you actually want to use 
Rcov is a handy tool to make sure that your tests have at least run every line of code in your application. This is very useful if you have forgotten to write a test for a method, or if inside of a method, you forgot to test a conditional statement. Because I find this handy, I incorporate the rcov plugin in my rails applications.
Running rake test:functionals:rcov, my report shows me a long list of items, some of which I don’t want to see. I don’t want to see the coverage of my models in the report. I should get that report by running rake test:units:rcov. Luckily, the plugin allows for me to set arguments like SHOW_ONLY="app/models". But get this, I’m lazy and I don’t want to type that argument let alone remember it every time I want to run the rcov tests. What to do?
Read the rest of this entry »
Blocks rock and I couldn’t agree more. The functional programming aspect of ruby has started to interest me more and more. Blocks are used all over the place, with respond_to, collect, returning, and ActionView::Helpers::FormHelper#form_for.
Sometimes, a design requires a little extra markup, perhaps something to get that rounded corner to work or whathave you. Now let’s say this piece of code requires certain classes, a certain kind of structure, including a tile, and has to be used in many places, something like a sidebar piece. Instead of copying and pasting this structure over and over, you can use a helper to make you life easier, and if you combine it with a block, it will just feel even more painless.
Read the rest of this entry »
Nobody likes to see exceptions when running an application; it means something went wrong and you should have been on top of it. But with that, often times I find people will write code to prevent exceptions rather than just allowing them to occur and then using it in their favor.
Take this bit of ruby code in a rails controller as an example:
class ArticlesController < ApplicationController
def show
@article = Article.find(params[:id])
end
end
That’s pretty solid, but what happens if someone passes in an ID that does not exist? Well in rails’ production mode, it would return a 404 error.
Makes sense! That article doesn’t exist, so it can’t be found. I have dabbled with a little SEO and usability and just a 404 isn’t cutting it for me. I think we can redirect our user back on a right track. For one, we know the user is trying to read an article, so why not redirect the user to a list of all the articles and give them a little warning?
Read the rest of this entry »
Now that that release candidate for rails 1.2 is out, people are going to have even more reasons to use the respond_to method in their controller methods. With that, there may come some unsettling feeling that you’re just repeating yourself over and over again.
def index
@articles = Article.find(:all)
respond_to do |format|
format.html
format.xml { render :xml => @articles.to_xml }
end
end
def show
@article = Article.find(params[:id])
respond_to do |format|
format.html
format.xml { render :xml => @article.to_xml }
end
end
If we want to use the respond_to, we have to make sure it’s in all of our methods. Wouldn’t it be easier to just do something like this?
def index
@articles = Article.find(:all)
format.html
format.xml { render :xml => @articles.to_xml }
end
Doing it this way, we don’t have to write 2 extra lines per method, and we don’t increase our indentation. While that’s not a huge thing, I still just don’t like to constantly write out those lines when I don’t have to when I think we can build something a little trickier.
Read the rest of this entry »
This is one of those things that is probably obvious to some, and just not known to some. I was in that latter description up until a few minutes ago. It’s that you can easily validate any belongs_to relationship by simply using valdiates_presence_of.
class Comment < ActiveRecord::Base
belongs_to :article
validates_presence_of :article
end
If you instantiate a new Comment, and don’t assign an Article to the comment instance, the record won’t save. I have to say, that seemed pretty obvious. But there is another interesting piece to this.
Say I passed the article_id in the params and tried to assign that to our instance
comment = Comment.new
comment.article_id = params[:article_id]
If article_id corresponds to a real article in our database, then comment.article will have be assigned an Article with that id@. Now if @params[:article_id] happens to be some id which doesn’t exist, like 99999999999, then comment.article will be nil and thus the record fails validation.
This means that you don’t have to test for the existence of the Article against your records because rails will do this for you when it checks to see if comment.article is nil or not.
This is a fairly simple little tidbit, but still useful. Sometimes I want to have a script for my rails application, like running some reports on the data. There are two basic ways to do this: write a task(rake), or create a new ruby script file, like in the scripts directory.
If you want to do the latter, then there are two lines you my want to put at the top of your script.
ENV['RAILS_ENV'] = ARGV.first || ENV['RAILS_ENV'] || ‘development’
require File.expand_path(File.dirname(__FILE__) + "/../config/environment")
The first line allows us to supply which environment we would like to run the script in. Say the script is called process.rb, we could call the script like ./process.rb production and now the environment is set to production.
The second line loads the environment file. Now all of rails, your models, libraries, and plugins are available to you.
I love migrations. I think they are one of the best things about rails. I love that I can count on any changes I’ve done in the database to be consistent across all other databases that I use. Love it.
Sometimes I find that I want pre-load my database with some data, like categories that I have. For testing purposes, I have already created this data in my fixture; now I just want to load that fixture into my database from a migration call.
I know that there is a rake task for this, so I looked into that code and came up with a little something.
Read the rest of this entry »
As a rails user who loves migrations, I have noticed that all of the migrations are prefixed with three decimal places, like 001_create_sessions.rb or something of that nature. That got me thinking, what would happen after I had 999 migrations?
That sets of the paranoia level up because who knows, I may need 1001 migrations! So to settle this once and for all, I wrote a script that would generate 999 migrations for me. I ran the 1000 migration and then it created 1001_test1001.rb.
Good news! Rails doesn’t constrain its migrations to a 3 decimal place prefix. So pointless…