:first and :all giving different first records

Rails
1

I’m trying to track down a strange test error. This project has Rails
2.1.0
frozen in vendor/rails . On my MacBook Pro, the problem boils down to
this:

(rdb:1) Invoice.first(:order=>‘id desc’)

#<Invoice id: 3, type: “Invoice”, name: “Invoice 1 for Job 1”, memo:
nil,
created_at: “2007-09-03 00:00:00”, updated_at: “2009-03-30 16:49:48”,
est_inv_number: “1-03”, status: “free”, qb_txn_id: nil, per_quote:
false,
bill_to: nil, printed_at: nil, emailed_at: nil, faxed_at: nil,
invoiceable_type: “Job”, invoiceable_id: 1, qb_sent_at: nil, company_id:
850010094, itemize_tax_markup: false, bill_to_customer_id: nil,
qb_class_override: nil, proposal_loaded: false, proposal_date: nil,
proposal_re: nil, proposal_attn: nil, proposal_body: nil,
proposal_include:
nil, proposal_exclude: nil, proposal_sig: nil, date: “2007-09-03”>

(rdb:1) Invoice.find(:all, :order=>‘id desc’).first

#<Invoice id: 9, type: “Invoice”, name: “Estimate 1 for Job 1”, memo:
nil,
created_at: “2009-03-30 16:52:48”, updated_at: “2009-03-30 16:52:48”,
est_inv_number: “1-05”, status: “free”, qb_txn_id: nil, per_quote:
false,
bill_to: nil, printed_at: nil, emailed_at: nil, faxed_at: nil,
invoiceable_type: “Job”, invoiceable_id: 1, qb_sent_at: nil, company_id:
850010094, itemize_tax_markup: false, bill_to_customer_id: nil,
qb_class_override: nil, proposal_loaded: false, proposal_date: nil,
proposal_re: nil, proposal_attn: nil, proposal_body: nil,
proposal_include:
nil, proposal_exclude: nil, proposal_sig: nil, date: “2009-03-30”>

I’m in the debugger in the middle of a test run. I have another Mac,
running the same version of the code, checked out from the same
repository,
on which this works fine. The SQL queries produced for these two lines
is
identical on both machines:

Invoice Load (0.000516) SELECT * FROM est_invs WHERE (
(est_invs.type = ‘Invoice’ ) ) ORDER BY id desc LIMIT 1

and

Invoice Load (0.000536) SELECT * FROM est_invs WHERE (
(est_invs.type = ‘Invoice’ ) ) ORDER BY id desc

Here’s another way of looking at the same weirdness:

(rdb:1) Invoice.first.id http://invoice.first.id/
3
(rdb:1) Invoice.last.id http://invoice.last.id/
3
(rdb:1) Invoice.all.map(&:id)
[3, 4, 5, 6, 9]
(rdb:1) Invoice.all.first.id http://invoice.all.first.id/
3
(rdb:1) Invoice.all.last.id http://invoice.all.last.id/
9

On my other Mac, running the same code, same test, etc., it looks like
this
(which is how it should look):

(rdb:1) Invoice.first.id http://invoice.first.id/
3
(rdb:1) Invoice.last.id http://invoice.last.id/
9
(rdb:1) Invoice.all.map(&:id)
[3, 4, 5, 6, 9]
(rdb:1) Invoice.all.first.id http://invoice.all.first.id/
3
(rdb:1) Invoice.all.last.id http://invoice.all.last.id/
9

I can’t figure out what’s going on. I’ve been staring at this off and
on
for days, and I’m out of ideas. Anyone have any good ones?

2

Ryan,

I had something similar on Rails 2.2.2 recently. In my case,
Object.first was returning nil but Object.all.first was working. I
banged my head for a bit then decided it wasn’t important to “solve”
it at this time as the client just needed the project done, so I left
it as Object.all.first, which isn’t as efficient, but still works.

I’d be interested if you figured this out. It seems so arbitrary.

One other thing that I would try if I were you: can you connect
directly to MySQL and try running the queries there by hand and see
what they return? That may help track down whether it’s even a Rails
issue at all. I use CocoaSQL on my mac which makes it really easy to
copy-n-paste the SQL queries from the log/debugger and try them.

If it works fine in SQL directly, then you’ve ruled that out and can
focus on Rails, AR, caching and the like. Try it from script/console
as well to rule out web server (which probably isn’t related anyway,
but it’s always good rule things out).

If it doesn’t work right in SQL, then you’ve ruled out Rails, and can
focus on what is screwed up with MySQL.

Best of luck! Post your response when you figure it out. :slight_smile:

-Danimal

3

On Mar 31, 4:20 pm, Danimal [email protected] wrote:

If it doesn’t work right in SQL, then you’ve ruled out Rails, and can
focus on what is screwed up with MySQL.

It’s a mysql bug: see http://bugs.mysql.com/bug.php?id=37830 and
http://lists.mysql.com/commits/49739

Fred

4

Thank you! That was it. You’re the man! :slight_smile:

I went ahead and jumped from MySQL 5.0.x to 5.1.32, so no doubt I will
soon
have new adventures to relate.

On Tue, Mar 31, 2009 at 10:39 AM, Frederick C. <