Simpltry

I am not quite prepared to call this a rails bug. But has_one definitely behaves weirdly in rails 2.1.

Lets say you have the following two models:

class Email < ActiveRecord::Base
  belongs_to :user
end

class User < ActiveRecord::Base
  has_one :email
end

A very straight forward has_one association. Now give the following from a script/console session:

>> user = User.first
=> #<User id: 1, created_at: "2008-07-09 01:19:11", updated_at: "2008-07-09 01:19:11">
>> user.email = Email.find(user.email.id)
=> #<Email id: 1, user_id: 1, created_at: "2008-07-09 01:19:26", updated_at: "2008-07-09 01:19:26">
>> user.reload
=> #<User id: 1, created_at: "2008-07-09 01:19:11", updated_at: "2008-07-09 01:19:11">
>> user.email
=> nil

That is weird. There is no reason you would do this in production, but if you were doing this you wouldn’t expect it to update the email row to set user_id to nil. Unfortunately, that is exactly what is happening.

Personally, I wouldn’t expect it to write anything to the database until I called save on user.

Anyone have a reasonable explanation, or should I submit it to Lighthouse.

As long as I can remember you could always eager load your associations in rails. If you wanted to find all your users companies, you could tell rails to do it in an efficient way.

There is no change in the code you write

User.all(:include => :company)

The SQL it used to generate was:

SELECT
  `users`.`id`      AS t0_r0
  `users`.`email   AS t0_r1
  . . .
FROM
  `users`
  LEFT OUTER JOIN `companies` ON `companies`.id = `users`.company_id

Fine, that isn’t really news, but now active_record splits that sql statement up into two statements.

SELECT * FROM `users`;
SELECT * FROM `companies`
  WHERE `companies`.id IN ('1','2', . . . );

Apparently this will be faster in most cases. I don’t have anything to say about that but, there are two interesting things I want to show you. They both involve :conditions.

If you put conditions on the users table it still generates two queries.

User.all(:include => :company,
  :conditions => "`users`.`email` LIKE '%gmail%'")

SELECT * FROM `users`
  WHERE `users`.`email` LIKE '%gmail%';
SELECT * FROM `companies`
  WHERE `companies`.id IN ('1','2', . . . );

But if you put conditions on the companies table it fails over to the old style and generates one statement

User.all(:include => :company,
  :conditions => "`companies`.`name` LIKE '%google%'")

SELECT
  `users`.`id`      AS t0_r0
  `users`.`email   AS t0_r1
  . . .
FROM
  `users`
  LEFT OUTER JOIN `companies` ON `companies`.id = `users`.company_id
WHERE
  `companies`.`name` LIKE '%google%'

I don’t know if they have to do it that way to get the correct results or what. But I thought it was interesting.

Steve Yegge of Google gave the above talk, entitled “Server-side JavaScript (SSJS) on the Java VM.” It is long but great, I highly recommend it. It isn’t really about SSJS, although he did write a SSJS web framework called, “Rhino’s not Ruby” RnR. Which is a port of rails to JavaScript. Which makes him sound crazy, but he does have his reasons.

The talk is much more about dynamic languages and dynamic languages on the JVM. Even though I have no interest in the JVM anymore, he raises some great points. It is also a very funny talk, Steve keeps you engaged throughout.

In no particular order

FiveRuns TuneUp

It is a tool for looking at what is make a request slow. The above screen shot shows the RideCharge landing page call stack.

Internally we hacked it so that it doesn’t run in development, but in a new environment development_tuneup. I also hacked it to ignore the idea of being logged in, to speed up adoption.

Passenger 2.0

I have long been a fan of mod_rails (now branded as passenger). There was a lot to be excited about in their talk. They talked about the release candidate features. But one of the most obvious (after you hear it) features was buffering file uploads. So, wait until the file is uploaded then dispatch to rails.

A Continued Commitment To Testing

The rails community has always been pretty committed to testing. It is our version of type safety. But, people are trying to do more and more testing in less and less time. There was a talk called “The Great Test Dance-Off” by Josh Susser. It was a pretty good summary of, Test::Unit vs. RSpec vs. Shoulda. David Chelimsky, RSpec Lead Developer, did a great write up on the talk. While I am a Shoulda man, I wholeheartedely agree with him that anything to get people testing and talking about testing is awesome.