# ActiveRecord count with grouped relations

**URL:** <https://discuss.rubyonrails.org/t/activerecord-count-with-grouped-relations/67968>\
**Category:** rubyonrails-core\
**Created:** [October 18, 2013, 12:55am UTC](https://discuss.rubyonrails.org/t/activerecord-count-with-grouped-relations/67968 "2013-10-18T00:55:57Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Andrew\_Vit](https://avatars.discourse-cdn.com/v4/letter/a/a8b319/32.png) [@Andrew\_Vit](https://discuss.rubyonrails.org/u/Andrew_Vit)\
**Post date:** [October 18, 2013, 12:55am UTC](https://discuss.rubyonrails.org/t/activerecord-count-with-grouped-relations/67968/1 "2013-10-18T00:55:57Z")

</div>

I’d like to try and revive discussion around these issues:

> <https://github.com/rails/rails/issues/7121>
>
> See \[runnable code example\](https://gist.github.com/3155195) in gist.
> 
> \*\*Goal:\*\*… get a count of rows from a query that includes pseudo columns and grouping.
> 
> When counting with grouping in the relation, ActiveRecord tries to return group counts instead of a total count and drops the SELECT on the floor. If there are pseudo-columns in the SELECT for grouping, this breaks the whole query.
> 
> Also, if it even worked, this would return a hash instead of a Fixnum. There doesn't
> seem to be a way to get the total of returned rows, ignoring the grouping.
> \- \`count\` should be usable to return a numeric count even when grouping is needed for the query.
> \- \`relation.count\` and \`relation.all.count\` should have the same semantics.
> \- \`count\` should work directly on any relation, so the relation can still be used as a chainable scope.
> 
> Suggestion for Rails 4: The Calculations#count method is too ambiguous and assumes too much. Change Calculations#count method to only return groups if a :group option is passed directly to the count method, i.e. do not trigger grouped counts based on other \`group\_values\` in the relation. That, or split #count and #count\_grouped into separate methods. This might make it easier to do the right thing with the query builder.
> 
> A simple first step might be to flag the relation so that it conditionally delegates \`.count\` to \`.all.count\` when the above situation occurs. Thoughts?

> <https://github.com/rails/arel/issues/83>
>
> Pretend I have a OutlandishClaim model, and each claim can have many sources.
> 
> \`…\`\`
> class OutlandishClaim \< ActiveRecord::Base
> has\_many :sources, :as =\> :sourceable
> 
> scope: sourced, joins(:sources).group("sourceable\_id")
> end
> \`\`\`
> 
> I'd like to get a list of all the OutlandishClaims that have been sourced. BUT, I can't do the following
> 
> \`\`\`
> OutlandishClaim.sourced.count
> \`\`\`
> 
> because it returns an ordered hash. It seems the \_count\_ method is reading the \_group\_ on the scope and thinking that I'd actually called
> 
> \`\`\`
> OutlandishClaim.sourced.count(:group =\> "sourceable\_id")
> \`\`\`
> 
> This behaviour requires anyone using this scope to know to call \_count\_ again on the hash to get the actual count. A la
> 
> \`\`\`
> OutlandishClaim.sourced.count.count
> \`\`\`
> 
> Unfortunately this is lame and also instantiates each record and then counts them. How it \_should\_ work is that count ignores any chained \_group\_ on the scope and only groups if you explicitly pass the option to \_count\_. This would allow for consistent counting behaviour, and in cases where I wanted it grouped, I could simply do as the Rails documentation states and pass the option to the \_count\_ method.

Originally, my thought for an easy solution was to hide the presence of group\_values inside a subquery using `from(relation.group(x)).count` as I suggested here:

[https://groups.google.com/forum/#!topic/rubyonrails-core/mwBehQcEduU](https://groups.google.com/forum/#!topic/rubyonrails-core/mwBehQcEduU)

SELECT COUNT(\*) FROM (SELECT \* FROM … GROUP BY …)

Unfortunately some databases (MySQL) are really inefficient at dealing with functions on subqueries like this. And ultimately, relying on subqueries to fix it for us is a hack just to get around the problem with blindly calling `count` and expecting an integer. I keep running into this problem regularly enough that I really want to work something out for separate and predictable “row count” and “grouped count” methods. Maybe something like one of these ideas I sketched out:

> <https://gist.github.com/avit/3681183>

Is there a way forward?

Andrew Vit