fetch ids without instantiating records using pluck

[ashanbrown]

Not only is pluck more efficient for fetching ids, but instantiating a record with only an id can cause problems isfthere are after_find hooks that expect to have all the columns populated. However, pluck was a rails 3.2 addition, so we have to test for it since this gem supports back to rails 3.0.0.

[seuros]

Nice! 👍 we don't need the test, the gem support 3.2+

Can you add also a note in the change log under 3.4.0 ?
while you are on it, please fix the markdown.

[ashanbrown]

I've amended the commit to always use pluck (for mysql only ... not sure about the other path). I've also updated the changelog and fixed the markdown. The gemspec requires active record >= 3. Maybe it should be updated to >= 3.2?

[seuros]

* [@twalpole Update for rails edge (4.2)](https://github.com/mbleigh/acts-as-taggable-on/pull/583)

[seuros]

Can you correct this one too ?

[seuros]

I already fixed the gemspec
plucks works for all databases. Let see how the tests go.

[ashanbrown]

I've updated the request to just replace select with pluck. As I read the code, mysql doesn't enjoy the benefit of making a single query, which is unfortunate. I know rails can automatically generated nested queries, but I'm having trouble getting that to work and I don't know what version that started with.

[seuros]

Look good to me. Thank you. We can optimize/fix later.

[ashanbrown]

Got it. Put the link in the changelog.

Regarding the the separate queries, it looks like that's why the code was refactored a bit (#457) and it fixes a problem with pagination. I wonder if we could just check if the query has a limit_value or offset_value, before deciding to make two queries on mysql, although I don't know how confident we can be that a paginator would build up the query using .limit and .offset. Probably ok though. Looks like kaminari and will_paginate both use .limit and .offset

[seuros]

Core need a full rewrite to use the rails way.