Anyone know what test_with_limiting_with_custom_select is testing ?

rubyonrails-core
1

finder_test.rb (in active_record) has this test:

def test_with_limiting_with_custom_select   posts = Post.find(:all, :include => :author, :select => ' posts.*, authors.id as "author_id"', :limit => 3, :order => 'posts.id')   assert_equal 3, posts.size   assert_equal [0, 1, 1], posts.map(&:author_id).sort end

But what is it testing (given that :include overwrites the select option) ?

If the select wasn't ignored then the test fails as the author_id from posts would be overwritten by the one from the select, ie the post with author_id 0 would get an author_id of NULL (which I found out precisely because I have altered old-skool include not to squash :select and this is the one failing test)

Fred

2

Frederick Cheung wrote:

finder_test.rb (in active_record) has this test:

def test_with_limiting_with_custom_select   posts = Post.find(:all, :include => :author, :select => ' posts.*,
authors.id as "author_id"', :limit => 3, :order => 'posts.id')   assert_equal 3, posts.size   assert_equal [0, 1, 1], posts.map(&:author_id).sort end

But what is it testing (given that :include overwrites the select
option) ?

Looks like what it's *meant* to be testing is that you can specify a custom :select while using :include. It's obviously doing a pretty poor job if this because:

1) You can't do this 2) the piggy-back attribute would be selected anyway.

So if you want to fix it you could update the column selected to be something else, with another name say REVERSE(authors.name) AS backwards_name.

3

Cool, that's what I thought. i'll do something like that then.

Fred