If you pass a :total_entires option to the paginate_by_sql method, it is ignored. Developers attempting to avoid costly repetition of the "select(*)" statement will find it creeping back into their logs.
Example:
# this code ought to generate a single select statement, returning the first 20 rows
m = Member.paginate_by_sql("select * from members", {:per_page => 20, :page => 1, :total_entries => 1000001})
Instead, it produces this SQL:
Member Load (0.001265) select * from members LIMIT 20 OFFSET 0
Member Count (0.583301) SELECT COUNT(*) FROM (select * from members) AS count_table
That's roughly 460 times as long as the call would take if the table count were cached. This caching is something I'm adding to my own application, but it depends on :total_entries being obeyed.
The option :total_entries is ignored by accident; when wp_parse_options! is called, it destroys the hash entry keyed on :total_entries. Unfortunately, paginate_by_sql throws away the returned value that was :total_entries and instead attempts to get it out of the options hash.
I've attached a patch that changes this behavior to the correct one: paginate_by_sql stores the returned value for total_entries and uses it.
The patch also includes an additional test for the finder: it checks to see whether the pager set up in paginate_by_sql has the correct value for total_entries. Someone might want to create a similar test for other pagination methods.
Chris Wanstrath
Mislav