Re: [Rails-core] ActiveRecord::Querying#find_by_sql has a confusing interface?

[Matias Korhonen]

There's also no test case (as far as I can find 
)
 
that would cover passing the binds args to #find_by_sql

Anyone know what it's supposed to be used for?



On Thursday, 25 June 2015 18:48:10 UTC+3, T.J. Schuck wrote:
>
> The `bind` argument was added as `bind_values` all the way back in 2010, 
> with no change to the documentation: 
> https://github.com/rails/rails/commit/cc468d3ec81d6f1298fca91c0549584b36dafcc6
>
> So the docs are probably just wrong — I’m sure a documentation PR would be 
> quickly merged.
>
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] [ANN] Rails 4.2.3 and 4.1.12 have been released!

[Rafael Mendonça França]

Hi everyone,

I am happy to announce that Rails 4.2.3 and 4.1.12 have been released.

No regressions were found so these releases include the same changes that
the release candidates.

## CHANGES since 4.1.11

To view the changes for each gem, please read the changelogs on GitHub:

* [Action Mailer CHANGELOG](
https://github.com/rails/rails/blob/v4.1.12/actionmailer/CHANGELOG.md)
* [Action Pack CHANGELOG](
https://github.com/rails/rails/blob/v4.1.12/actionpack/CHANGELOG.md)
* [Action View CHANGELOG](
https://github.com/rails/rails/blob/v4.1.12/actionview/CHANGELOG.md)
* [Active Model CHANGELOG](
https://github.com/rails/rails/blob/v4.1.12/activemodel/CHANGELOG.md)
* [Active Record CHANGELOG](
https://github.com/rails/rails/blob/v4.1.12/activerecord/CHANGELOG.md)
* [Active Support CHANGELOG](
https://github.com/rails/rails/blob/v4.1.12/activesupport/CHANGELOG.md)
* [Railties CHANGELOG](
https://github.com/rails/rails/blob/v4.1.12/railties/CHANGELOG.md)

*Full listing*

To see the full list of changes, [check out all the commits on
GitHub](https://github.com/rails/rails/compare/v4.1.11...v4.1.12).

## CHANGES since 4.2.2

To view the changes for each gem, please read the changelogs on GitHub:

* [Action Mailer CHANGELOG](
https://github.com/rails/rails/blob/v4.2.3/actionmailer/CHANGELOG.md)
* [Action Pack CHANGELOG](
https://github.com/rails/rails/blob/v4.2.3/actionpack/CHANGELOG.md)
* [Action View CHANGELOG](
https://github.com/rails/rails/blob/v4.2.3/actionview/CHANGELOG.md)
* [Active Model CHANGELOG](
https://github.com/rails/rails/blob/v4.2.3/activemodel/CHANGELOG.md)
* [Active Record CHANGELOG](
https://github.com/rails/rails/blob/v4.2.3/activerecord/CHANGELOG.md)
* [Active Support CHANGELOG](
https://github.com/rails/rails/blob/v4.2.3/activesupport/CHANGELOG.md)
* [Active Job CHANGELOG](
https://github.com/rails/rails/blob/v4.2.3/activejob/CHANGELOG.md)
* [Railties CHANGELOG](
https://github.com/rails/rails/blob/v4.2.3/railties/CHANGELOG.md)

*Full listing*

To see the full list of changes, [check out all the commits on
GitHub](https://github.com/rails/rails/compare/v4.2.2...v4.2.3).

## SHA-1

If you'd like to verify that your gem is the same as the one I've uploaded,
please use these SHA-1 hashes.

Here are the checksums for 4.1.12:

```
$ shasum *4.1.12*
c4f8aebcd59011e47d373a99413dad210e3d4bbd  actionmailer-4.1.12.gem
ce8868972769ad56b93b7b98585d64804d6d8174  actionpack-4.1.12.gem
2d6e6c6212bff10993394c63b56ce434342c9a47  actionview-4.1.12.gem
9a462b3ad2cfaf5f7914869efd5e8c62e54064b0  activemodel-4.1.12.gem
c0d65ed4f79115f7a9901d60201e720a7f556335  activerecord-4.1.12.gem
97fd3230896d900923dc650e788ccaaf3b06d692  activesupport-4.1.12.gem
9f6db196328b302c4c3a7ff3a1c7cd1a191221cc  rails-4.1.12.gem
8c7c04045df2eebc69e54c8426def69eca0f8bf6  railties-4.1.12.gem
```

Here are the checksums for 4.2.3:

```
$ shasum *4.2.3*
f02da8c3896d4c8cd208b7c555c2c2235e44ce0e  actionmailer-4.2.3.gem
d824941013ba3616aa643d4c5016d00bf2dc028f  actionpack-4.2.3.gem
53982ad7579069c2a5de4939bb8c689550bdd2ab  actionview-4.2.3.gem
280e774caf7335aba1b50441b4890803d18a666c  activejob-4.2.3.gem
0d2160b37223703d167cfd5a8cb358029ccbacd9  activemodel-4.2.3.gem
8799d638cc5cdbd59296392f0f1014a051378517  activerecord-4.2.3.gem
1dc5e9cba144dc9794bc4ebed19a8528b7287a76  activesupport-4.2.3.gem
0ef8f13382996c3480d09900e34988aae85f0886  rails-4.2.3.gem
0fa6b51c3e9f70f0ce9fb1d1977169537d19ae86  railties-4.2.3.gem
```

I'd like to thank you all, every contributor who helped with this release.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] ActiveRecord::Querying#find_by_sql has a confusing interface?

[Al Tenhundfeld]

If I'm following the code, it looks like the binds argument is passed
through #select_all and eventually down to the adapter's #exec_query, e.g.,
the MySQL adapter
.
So, the behavior could be different depending on the adapter and even DB
version. That makes sense, because different databases handle prepared
statements and bind variables differently.

And it looks like the documentation example of #find_by_sql, passing the
array with "bind variables" into the sql arg, works because that sql arg is
being passed to #sanitize_sql
,
which has its own implementation of replacing variables outside of/before
the adapter. So, using this syntax isn't really using bind variables,
passed to the database. It's more string interpolation and sanitation.

So, following the code, I was able to get a query executing with the
Postgres adapter and actually passing the bind variables to Postgres.

*Example 1, using binds arg:*
Project.find_by_sql('select * from projects where client_id = $1 and region
= $2', [[nil, 123], [nil, 'West']])
(NOTE: You can use the column name in place of nil, but I get a warning
when I do that.)
Results in this statements in the PG log:
LOG:  execute a3: select * from projects where client_id = $1 and region =
$2
DETAIL:  parameters: $1 = '123', $2 = 'West'

*Example 2, specifying the variables in the sql arg:*
Project.find_by_sql(['select * from projects where client_id = ? and region
= ?',123, 'West'])
Results in:
LOG:  execute : select * from projects where client_id = 123 and
region = 'West'

So, you can see those are clearly different. In example 1, the statement is
being prepared, and the bind variables are passed to Postgres. In example
2, the variables are being replaced by Rails via #sanitize_sql before the
statement is passed on to the adapter, which results in an unnamed
statement passed to Postgres with no bind variables. (I think, that's how
I'm interpreting it at least.)

I couldn't get a true bind variable example working with MySQL, but I don't
have a convenient environment using recent versions of the adapter and
MySQL server. I think this is related to Pat Shaughnessy's post on prepared
statements

.

Following that logic, it's not too surprising that standard model methods
result in different behavior in PG and MySQL:

Project.find(1) using the Postgres adapter results in:
LOG:  execute a4: SELECT  "projects".* FROM "projects"  WHERE
"projects"."id" = $1 LIMIT 1
DETAIL:  parameters: $1 = '1'

Project.find(1) using (my older version of) the MySQL adapter results in
the MySQL equivalent of:
LOG:  execute : SELECT  "projects".* FROM "projects"  WHERE
"projects"."id" = 1 LIMIT 1

I haven't really kept up with database internals enough to know how much of
an improvement prepared statements yield. Years ago, prepared statements
could give you a significant performance improvement, because the query
parser can easily see two queries are the same, reuse copies of the
execution plan, etc. My understanding is databases have gotten better about
deriving similarities in queries and reusing plans, cached results, etc.

I don't have an opinion (yet) on what should be done to improve the
situation, but I hope that sheds a little light on what's happening with
the binds arg and why you might want to use it.

Cheers,
Al




On Fri, Jun 26, 2015 at 3:01 AM, Matias Korhonen 
wrote:

> There's also no test case (as far as I can find
> )
> that would cover passing the binds args to #find_by_sql
>
> Anyone know what it's supposed to be used for?
>
>
>
> On Thursday, 25 June 2015 18:48:10 UTC+3, T.J. Schuck wrote:
>>
>> The `bind` argument was added as `bind_values` all the way back in 2010,
>> with no change to the documentation:
>> https://github.com/rails/rails/commit/cc468d3ec81d6f1298fca91c0549584b36dafcc6
>>
>> So the docs are probably just wrong — I’m sure a documentation PR would
>> be quickly merged.
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receivi

Re: [Rails-core] ActiveRecord::Querying#find_by_sql has a confusing interface?

[Roque Pinel]

I believe the binds are used to improve the statement caching and not
suggested to be used directly.

Here is an example of an internal use when `Post.find(1)` executed:

id_query_attribute = ActiveRecord::Relation::QueryAttribute.new(:id, 1,
Post.type_for_attribute(:id))
Post.find_by_sql('select * from posts where id = ?', [id_query_attribute])

On Fri, Jun 26, 2015 at 1:05 PM, Al Tenhundfeld 
wrote:

> If I'm following the code, it looks like the binds argument is passed
> through #select_all and eventually down to the adapter's #exec_query, e.g.,
> the MySQL adapter
> .
> So, the behavior could be different depending on the adapter and even DB
> version. That makes sense, because different databases handle prepared
> statements and bind variables differently.
>
> And it looks like the documentation example of #find_by_sql, passing the
> array with "bind variables" into the sql arg, works because that sql arg is
> being passed to #sanitize_sql
> ,
> which has its own implementation of replacing variables outside of/before
> the adapter. So, using this syntax isn't really using bind variables,
> passed to the database. It's more string interpolation and sanitation.
>
> So, following the code, I was able to get a query executing with the
> Postgres adapter and actually passing the bind variables to Postgres.
>
> *Example 1, using binds arg:*
> Project.find_by_sql('select * from projects where client_id = $1 and
> region = $2', [[nil, 123], [nil, 'West']])
> (NOTE: You can use the column name in place of nil, but I get a warning
> when I do that.)
> Results in this statements in the PG log:
> LOG:  execute a3: select * from projects where client_id = $1 and region =
> $2
> DETAIL:  parameters: $1 = '123', $2 = 'West'
>
> *Example 2, specifying the variables in the sql arg:*
> Project.find_by_sql(['select * from projects where client_id = ? and
> region = ?',123, 'West'])
> Results in:
> LOG:  execute : select * from projects where client_id = 123 and
> region = 'West'
>
> So, you can see those are clearly different. In example 1, the statement
> is being prepared, and the bind variables are passed to Postgres. In
> example 2, the variables are being replaced by Rails via #sanitize_sql
> before the statement is passed on to the adapter, which results in an
> unnamed statement passed to Postgres with no bind variables. (I think,
> that's how I'm interpreting it at least.)
>
> I couldn't get a true bind variable example working with MySQL, but I
> don't have a convenient environment using recent versions of the adapter
> and MySQL server. I think this is related to Pat Shaughnessy's post on 
> prepared
> statements
> 
> .
>
> Following that logic, it's not too surprising that standard model methods
> result in different behavior in PG and MySQL:
>
> Project.find(1) using the Postgres adapter results in:
> LOG:  execute a4: SELECT  "projects".* FROM "projects"  WHERE
> "projects"."id" = $1 LIMIT 1
> DETAIL:  parameters: $1 = '1'
>
> Project.find(1) using (my older version of) the MySQL adapter results in
> the MySQL equivalent of:
> LOG:  execute : SELECT  "projects".* FROM "projects"  WHERE
> "projects"."id" = 1 LIMIT 1
>
> I haven't really kept up with database internals enough to know how much
> of an improvement prepared statements yield. Years ago, prepared statements
> could give you a significant performance improvement, because the query
> parser can easily see two queries are the same, reuse copies of the
> execution plan, etc. My understanding is databases have gotten better about
> deriving similarities in queries and reusing plans, cached results, etc.
>
> I don't have an opinion (yet) on what should be done to improve the
> situation, but I hope that sheds a little light on what's happening with
> the binds arg and why you might want to use it.
>
> Cheers,
> Al
>
>
>
>
> On Fri, Jun 26, 2015 at 3:01 AM, Matias Korhonen 
> wrote:
>
>> There's also no test case (as far as I can find
>> )
>> that would cover passing the binds args to #find_by_sql
>>
>> Anyone know what it's supposed to be used for?
>>
>>
>>
>> On Thursday, 25 June 2015 18:48:10 UTC+3, T.J. Schuck wrote:
>>>
>>> The `bind` argument was added as `bind_values` all the way back in 2010,
>>> with no change to the documentation:
>>> https://github.com/rails/rails/commit/cc468d3ec81d6f1298fca91c0549584b36dafcc6
>>>
>>> So the docs are probably just wrong — I’m sure a documentation PR would
>>> be quickly merged.
>>>
>>>  --
>> You received this message b

Re: [Rails-core] ActiveRecord::Querying#find_by_sql has a confusing interface?

[Al Tenhundfeld]

Ah, QueryAttribute was the part I was missing, didn't have time to dig
through the code and follow how something like #find was specifying the
bind variables (correctly). That makes sense.

Thanks,
Al

On Fri, Jun 26, 2015 at 2:10 PM, Roque Pinel  wrote:

> I believe the binds are used to improve the statement caching and not
> suggested to be used directly.
>
> Here is an example of an internal use when `Post.find(1)` executed:
>
> id_query_attribute = ActiveRecord::Relation::QueryAttribute.new(:id, 1,
> Post.type_for_attribute(:id))
> Post.find_by_sql('select * from posts where id = ?', [id_query_attribute])
>
> On Fri, Jun 26, 2015 at 1:05 PM, Al Tenhundfeld 
> wrote:
>
>> If I'm following the code, it looks like the binds argument is passed
>> through #select_all and eventually down to the adapter's #exec_query, e.g.,
>> the MySQL adapter
>> .
>> So, the behavior could be different depending on the adapter and even DB
>> version. That makes sense, because different databases handle prepared
>> statements and bind variables differently.
>>
>> And it looks like the documentation example of #find_by_sql, passing the
>> array with "bind variables" into the sql arg, works because that sql arg is
>> being passed to #sanitize_sql
>> ,
>> which has its own implementation of replacing variables outside of/before
>> the adapter. So, using this syntax isn't really using bind variables,
>> passed to the database. It's more string interpolation and sanitation.
>>
>> So, following the code, I was able to get a query executing with the
>> Postgres adapter and actually passing the bind variables to Postgres.
>>
>> *Example 1, using binds arg:*
>> Project.find_by_sql('select * from projects where client_id = $1 and
>> region = $2', [[nil, 123], [nil, 'West']])
>> (NOTE: You can use the column name in place of nil, but I get a warning
>> when I do that.)
>> Results in this statements in the PG log:
>> LOG:  execute a3: select * from projects where client_id = $1 and region
>> = $2
>> DETAIL:  parameters: $1 = '123', $2 = 'West'
>>
>> *Example 2, specifying the variables in the sql arg:*
>> Project.find_by_sql(['select * from projects where client_id = ? and
>> region = ?',123, 'West'])
>> Results in:
>> LOG:  execute : select * from projects where client_id = 123 and
>> region = 'West'
>>
>> So, you can see those are clearly different. In example 1, the statement
>> is being prepared, and the bind variables are passed to Postgres. In
>> example 2, the variables are being replaced by Rails via #sanitize_sql
>> before the statement is passed on to the adapter, which results in an
>> unnamed statement passed to Postgres with no bind variables. (I think,
>> that's how I'm interpreting it at least.)
>>
>> I couldn't get a true bind variable example working with MySQL, but I
>> don't have a convenient environment using recent versions of the adapter
>> and MySQL server. I think this is related to Pat Shaughnessy's post on 
>> prepared
>> statements
>> 
>> .
>>
>> Following that logic, it's not too surprising that standard model methods
>> result in different behavior in PG and MySQL:
>>
>> Project.find(1) using the Postgres adapter results in:
>> LOG:  execute a4: SELECT  "projects".* FROM "projects"  WHERE
>> "projects"."id" = $1 LIMIT 1
>> DETAIL:  parameters: $1 = '1'
>>
>> Project.find(1) using (my older version of) the MySQL adapter results in
>> the MySQL equivalent of:
>> LOG:  execute : SELECT  "projects".* FROM "projects"  WHERE
>> "projects"."id" = 1 LIMIT 1
>>
>> I haven't really kept up with database internals enough to know how much
>> of an improvement prepared statements yield. Years ago, prepared statements
>> could give you a significant performance improvement, because the query
>> parser can easily see two queries are the same, reuse copies of the
>> execution plan, etc. My understanding is databases have gotten better about
>> deriving similarities in queries and reusing plans, cached results, etc.
>>
>> I don't have an opinion (yet) on what should be done to improve the
>> situation, but I hope that sheds a little light on what's happening with
>> the binds arg and why you might want to use it.
>>
>> Cheers,
>> Al
>>
>>
>>
>>
>> On Fri, Jun 26, 2015 at 3:01 AM, Matias Korhonen > > wrote:
>>
>>> There's also no test case (as far as I can find
>>> )
>>> that would cover passing the binds args to #find_by_sql
>>>
>>> Anyone know what it's supposed to be used for?
>>>
>>>
>>>
>>> On Thursday, 25 June 2015 18:48:10 UTC+3, 

Re: [Rails-core] Add a hash pluck method?

[Al Tenhundfeld]

The proposed method has more benefit when plucking multiple columns. Of
course, you can still do pluck(:first, :last, :dob).map {|e| {first: e[0],
last: e[1], dob: e[2]} }, but I guess that's a little cumbersome and
smelly. I'm not arguing the benefit – small benefit IMO – is worth the cost
of adding and maintaining for years, but I do see its convenience.

-Al

On Thu, Jun 25, 2015 at 5:39 PM, Ryan Bigg  wrote:

> What is the benefit of this method?
>
> You can pluck(:firstname).map { |e| { firstname: e } } if you really
> wanted that. Why are you plucking and wanting it to be a hash?
>
>
>
> On 25 Jun 2015, at 19:59, Mike Campbell  wrote:
>
> The regular AR pluck method returns the values only, for instance:
> Student.pluck(:firstname) => ["John", "Mike", "Simon"]
>
> It'd be a nice feature to have a version which returns a hashes with the
> column names as keys: [{ firstname: "John"}, { firstname: "Mike" }, {
> firstname: "Simon" }]
>
> I know this can (almost) be achieved with
> Student.select(:firstname).map(&:attributes) (it forces you to have an id
> attribute), but this involves instantiating lots of AR objects, which loses
> the benefit of pluck.
>
> An example implementation would be:
>
> def self.hash_pluck(*keys)
>   pluck(*keys).map{ |vals| Hash[keys.zip(Array(vals))] }
> end
>
> In some (probably bad) benchmarks I made comparing this to the select
> alternative, the select method was ~3.4x slower.
>
> Benchmark.ips do |x|
>   x.report("hash_pluck") { Student.hash_pluck(:firstname) }
>   x.report("select") { Student.select(:firstname).map(&:attributes) }
>   x.compare!
> end
>
> Calculating -
>   select 6.000  i/100ms
>   hash_pluck24.000  i/100ms
> -
>   select 77.096  (±29.8%) i/s -342.000
>   hash_pluck265.316  (±41.8%) i/s -  1.104k
>
> Comparison:
>   hash_pluck:  265.3 i/s
>   select:   77.1 i/s - 3.44x slower
>
> Just thought that it might be a nice convenience method to have!
>
> Cheers,
> Mike
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Add a hash pluck method?

[Nicholas Firth-McCoy]

I would definitely use this, given we don't currently have many good 
options for querying against the database and getting non-ActiveRecord 
objects back.

I often want a fast way to serialize stuff as JSON (ie. without 
instantiating AR objects and then turning them back into hashes), and doing 
this using `select_values` is pretty cumbersome.

For example: `render json: { tasks: current_user.tasks.hash_pluck(:id, 
:name, :completed) }`

That said, I'd probably favour a more general way to query the database and 
get back arrays/hashes over something like `hash_pluck`, which would only 
handle very simple cases.

On Saturday, June 27, 2015 at 4:35:30 AM UTC+10, Al Tenhundfeld wrote:
>
> The proposed method has more benefit when plucking multiple columns. Of 
> course, you can still do pluck(:first, :last, :dob).map {|e| {first: e[0], 
> last: e[1], dob: e[2]} }, but I guess that's a little cumbersome and 
> smelly. I'm not arguing the benefit – small benefit IMO – is worth the cost 
> of adding and maintaining for years, but I do see its convenience.
>
> -Al
>
> On Thu, Jun 25, 2015 at 5:39 PM, Ryan Bigg  > wrote:
>
>> What is the benefit of this method?
>>
>> You can pluck(:firstname).map { |e| { firstname: e } } if you really 
>> wanted that. Why are you plucking and wanting it to be a hash? 
>>
>>  
>>
>> On 25 Jun 2015, at 19:59, Mike Campbell > > wrote:
>>
>> The regular AR pluck method returns the values only, for instance: 
>> Student.pluck(:firstname) => ["John", "Mike", "Simon"]
>>
>> It'd be a nice feature to have a version which returns a hashes with the 
>> column names as keys: [{ firstname: "John"}, { firstname: "Mike" }, { 
>> firstname: "Simon" }]
>>
>> I know this can (almost) be achieved with 
>> Student.select(:firstname).map(&:attributes) (it forces you to have an id 
>> attribute), but this involves instantiating lots of AR objects, which loses 
>> the benefit of pluck.
>>
>> An example implementation would be:
>>
>> def self.hash_pluck(*keys)
>>   pluck(*keys).map{ |vals| Hash[keys.zip(Array(vals))] }
>> end
>>
>> In some (probably bad) benchmarks I made comparing this to the select 
>> alternative, the select method was ~3.4x slower.
>>
>> Benchmark.ips do |x|
>>   x.report("hash_pluck") { Student.hash_pluck(:firstname) }
>>   x.report("select") { Student.select(:firstname).map(&:attributes) }
>>   x.compare!
>> end
>>
>> Calculating -
>>   select 6.000  i/100ms
>>   hash_pluck24.000  i/100ms
>> -
>>   select 77.096  (±29.8%) i/s -342.000 
>>   hash_pluck265.316  (±41.8%) i/s -  1.104k
>>
>> Comparison:
>>   hash_pluck:  265.3 i/s
>>   select:   77.1 i/s - 3.44x slower
>>
>> Just thought that it might be a nice convenience method to have!
>>
>> Cheers,
>> Mike
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to rubyonrails-co...@googlegroups.com .
>> To post to this group, send email to rubyonra...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to rubyonrails-co...@googlegroups.com .
>> To post to this group, send email to rubyonra...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.