This project is archived and is in readonly mode.

#2189 ✓resolved
nkryptic

count breaks has_many through association collection with named scope

Reported by nkryptic | March 10th, 2009 @ 12:12 AM | in 3.0.5

It appears that commit 6543426c73 causes a count query to break when it is called on a has_many through association collection with a named scope:


class Member
  # has publisher boolean attribute
  named_scope :publishers, :conditions => { :publisher => true }
  has_many :memberships
  has_many :groups, :through => :memberships
end

class Membership
  belongs_to :member
  belongs_to :group
end

class Group
  has_many :memberships
  has_many :members, :through => :memberships
end

group = Group.new
group.members.publishers.count =>
# SQLite3::SQLException: near "*": syntax error: SELECT count("members".*) AS count_members_all FROM "members"...

It would seem that the commit changed the case statement for construct_count_options_from_args in activerecord/lib/active_record/calculations.rb to use the select from any :find scope:


column_name = scope(:find)[:select] if scope(:find)

This results in the column name of "tablename".*, which sqlite doesn't like in a count statement. This behavior only occurs on the has_many through relationship, could not get it to occur with any others - named_scope or not.

Comments and changes to this ticket

  • nkryptic

    nkryptic March 10th, 2009 @ 12:14 AM

    BTW, I've worked-around the issue by passing :select => "*" to the count method for now:

    
group.members.publishers.count(:select => "*")
  • Manfred Stienstra

    Manfred Stienstra March 10th, 2009 @ 11:05 AM

    This also doesn't work on MySQL 5.1.

  • Manfred Stienstra

    Manfred Stienstra March 10th, 2009 @ 02:35 PM

    Attached is a quick fix for the problem, I'm not quite sure how to solve this in a more general way because you never know where the :select is coming from.

    Specifying :select => '*' is not a real solution because you don't want to do that for empty? and such.

  • Will Bryant

    Will Bryant March 11th, 2009 @ 10:42 AM

    This affects mysql 5.0 also, and is definitely a regression.

  • Tom Stuart

    Tom Stuart March 16th, 2009 @ 03:39 PM

    Associations are one source of :select options, but more generally:

    
class Account < ActiveRecord::Base
  named_scope :account_fields_only, :select => 'accounts.*'
end

    
>> Account.account_fields_only.count
ActiveRecord::StatementInvalid: Mysql::Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '*) AS count_accounts_all FROM `accounts`' at line 1: SELECT count(accounts.*) AS count_accounts_all FROM `accounts`
  • larsthegeek

    larsthegeek March 16th, 2009 @ 05:49 PM

    Note that this also seems to break paginating results using will_paginate.

    For example, this code now breaks. Note that:

    User has_many :posts, :through=> :contributions

    
class Post < ActiveRecord::Base
  named_scope :published, :conditions => "posts`.state='ok'"
end

@posts = @user.posts.published.paginate :page => page, :per_page => "10"
  • Peter Wagenet

    Peter Wagenet March 16th, 2009 @ 07:37 PM

    • Tag set to “activerecord, calculations, patch, scope, tested”
    • Title changed from “count breaks sqlite has_many through association collection with named scope” to “count breaks has_many through association collection with named scope”

    I've been examining this as it breaks one of my apps as well. I think Manfred's solution is the best so far. I don't really see any issues with it as I can't imagine any counting scenarios where it wouldn't be appropriate to turn "table." into "". As long as no one can think of anything I think we should do that. Essentially we're just sanitizing the select field to make it appropriate for count.

  • Manfred Stienstra

    Manfred Stienstra March 16th, 2009 @ 07:47 PM

    • Tag changed from “activerecord, calculations, patch, scope, tested” to “2.3.2, activerecord, bug, calculations, patch, scope, tested, verified”

    My patch wasn't meant as a maintainable solution, but because a complete rewrite of scopes is going to take a while it might be best to apply it for now as it seems to bite quite a few people ):

  • Peter Wagenet

    Peter Wagenet March 16th, 2009 @ 08:01 PM

    Putting the attached file in your initializers should provide a temporary fix as well.

  • Peter Wagenet

    Peter Wagenet March 16th, 2009 @ 08:05 PM

    Others may disagree, but I'm not sure that this would merit a complete rewrite of scopes. As far as I know, the only alternative to COUNT(table.) is just COUNT(). You've provide a sanitizer method to make sure that any requests with "table." become "" and that seems appropriate enough.

  • Rufo Sanchez

    Rufo Sanchez March 16th, 2009 @ 09:07 PM

    I think there's a typo in the regex in count_fix.rb - I had a few specs that ran counts on uniq'd has_manys that were failing:

    
SQLite3::SQLException: near "*": syntax error: SELECT count(DISTINCT *) AS count_all FROM "assets" INNER JOIN "shipment_order_items" ON "assets".id = "shipment_order_items".asset_id WHERE (("shipment_order_items".shipment_order_id = 1))

    I changed line 14 of count_fix.rb to:

    
column_name = '*' if column_name =~ /\.\*$/ # was /\.*$/, was looking for any number of periods instead of specifically .*

    I've uploaded a count_fix.rb that should fix that, and hopefully not break anything else (at the least, my counts on scoped has_many :throughs appear to be working.)

  • Peter Wagenet

    Peter Wagenet March 16th, 2009 @ 10:32 PM

    Whoops, thanks for catching that.

  • Miha Filej

    Miha Filej March 18th, 2009 @ 05:31 PM

    • Tag changed from “2.3.2, activerecord, bug, calculations, patch, scope, tested, verified” to “2.3.2, activerecord, bug, calculations, patch, regression, scope, tested, verified”

    Thanks for the workaround. What do you think about changing line 14 into:

    
column_name.sub!('*', primary_key) if column_name =~ /\.\*$/
  • Peter Wagenet

    Peter Wagenet March 18th, 2009 @ 05:39 PM

    I could do that too. Does anyone have thoughts on what's more appropriate?

  • Will Bryant

    Will Bryant March 19th, 2009 @ 03:46 AM

    I would prefer substituting the primary key, personally, as I feel it makes it more clear what we're doing and makes me less nervous about counts with joins (which aren't really well handled yet elsewhere, but we might as well start...)

  • Thomas Steinhausen

    Thomas Steinhausen March 19th, 2009 @ 01:18 PM

    The problem also occurs if you use a :select option in named_scope, eg: ... named_scope :grouped, :group => 'search_query',

    :select => "MAX(id) AS id, MAX(created_at) AS created_at, search_query"

    ...

    ARModel.grouped.empty? then fails with an SQL error similar to the one mentioned.

  • Peter Wagenet

    Peter Wagenet March 19th, 2009 @ 01:29 PM

    Hmm, yeah the real difficulty here is the fact that what's normally acceptable for a SELECT statement is not acceptable for a count statement. The question then becomes how one can reasonably translate that statement into a legitimate count statement. Unfortunately, I can't think of a simple straight-forward way to do that.

    We could use a two step process like: 1) Translate table.* to table.primary_key 2) Anything still not valid we do a find and then do a size on the returned array.

    Or we could try something a little less pretty, though more reliable: Allow users to specify a :count_select in addition to their normal :select statement.

  • Manfred Stienstra

    Manfred Stienstra March 19th, 2009 @ 01:32 PM

    Peter, care to write a patch?

  • Peter Wagenet

    Peter Wagenet March 19th, 2009 @ 02:18 PM

    For which solution?

  • Max Lapshin

    Max Lapshin March 23rd, 2009 @ 04:35 PM

    • Assigned user set to “Pratik”
  • Mina Naguib

    Mina Naguib March 27th, 2009 @ 01:45 PM

    Regarding the above comments of using the primary_key in the count

    Please keep in mind that in many databases (certainly the ones I've worked on) there's a big difference between COUNT(*) and COUNT(field)

    COUNT(*) is what we're all familiar with. The number of rows the select would have returned

    COUNT(field) however only returns the number of NON-NULL entries in that field.

    Example: select count(*) from users; => 100

    select count(last_logged_in) from users; => 50

  • James Le Cuirot

    James Le Cuirot March 27th, 2009 @ 02:11 PM

    I hit a very similar issue, which I reported in ticket #2329. As well as having . in :select, I also had a calculated column, hence there was a comma in there. I came up with a one-line fix to change column_name to :all if :select contains a comma but I guess this wouldn't fix the case where you just have ..

    
--- a/activerecord/lib/active_record/calculations.rb
+++ b/activerecord/lib/active_record/calculations.rb
@@ -164,6 +164,7 @@ module ActiveRecord
             raise ArgumentError, "Unexpected parameters passed to count(): #{args.inspect}"
           end
 
+          column_name = :all if column_name.to_s.index(',')
           [column_name || :all, options]
         end
  • James Le Cuirot

    James Le Cuirot March 27th, 2009 @ 02:12 PM

    Sorry. Stupid Markdown...

    I hit a very similar issue, which I reported in ticket #2329. As well as having .* in :select, I also had a calculated column, hence there was a comma in there. I came up with a one-line fix to change column_name to :all if :select contains a comma but I guess this wouldn't fix the case where you just have .*.

  • Mislav

    Mislav March 27th, 2009 @ 04:40 PM

    @Mina: primary keys can't be NULL.

    My vote is for:

    
COUNT(`[table]`.[primary_key])

    It just feels more right. It will also produce correct counts if users get wild with all sorts of manual JOINs.

  • Max Lapshin

    Max Lapshin March 27th, 2009 @ 06:40 PM

    My vote is also for table.primary_key

  • Peter Wagenet

    Peter Wagenet March 27th, 2009 @ 09:54 PM

    Seeing as the primary key should always be populated, counting it should get you the same result as COUNT(*).

  • Xavier Shay

    Xavier Shay March 29th, 2009 @ 10:40 PM

    +1 count(*)

    fix the regression now, worry about more obscure edge cases later when we have real use cases rather than theoretical ones (or time to think through theoretical ones).

  • Wiktor Schmidt

    Wiktor Schmidt March 30th, 2009 @ 02:07 PM

    +1 count(*)

  • Nate

    Nate March 30th, 2009 @ 10:49 PM

    What's holding this up?

  • Pratik

    Pratik March 30th, 2009 @ 10:52 PM

    • Assigned user cleared.
  • Marc Bowes

    Marc Bowes April 1st, 2009 @ 09:56 PM

    This bug is pain. +1 vote fix asap, don't care how.

  • Christos Zisopoulos

    Christos Zisopoulos April 2nd, 2009 @ 03:25 PM

    +1 count(*)

  • Manfred Stienstra

    Manfred Stienstra April 2nd, 2009 @ 03:34 PM

    Hey guys, please don't just comment with just +1, it doesn't really help, it only annoys active developers who get assigned to the patch and they stop watching the tickets

    Voting is meant for an actual patch after you've reviewed it, not for some abstract solution that isn't actually implemented.

    From the contributers guide:

    If your comment simply says +1, then odds are other reviewers aren't going to take it too seriously. Show that you took the time to review the patch. Once three people have approved it, add the verified tag. This will bring it to the attention of a committer who'll then review the changes looking for the same kinds of things.

  • Steven Soroka

    Steven Soroka April 2nd, 2009 @ 03:49 PM

    Okay, I applied this patch in my app, (Rails 2.3.2) as such:

    
module CountFix
  def self.included(base)
    base.class_eval do
      extend ClassMethods
      class << self; alias_method_chain :construct_count_options_from_args, :fix; end
    end
  end
  
  module ClassMethods
    protected
      def construct_count_options_from_args_with_fix(*args)
        column_name, options = construct_count_options_from_args_without_fix(*args)
        column_name = '*' if column_name =~ /\.\*$/
        [column_name, options]
      end
  end
end
ActiveRecord::Base.send :include, CountFix

    It's a rather large app. Here's the last line of rake stats:

    Code LOC: 14241 Test LOC: 18787 Code to Test Ratio: 1:1.3

    So far no issues, all specs pass. +1 :)

  • Guillermo Álvarez

    Guillermo Álvarez April 2nd, 2009 @ 04:30 PM

    I think there is a problem in rails.

    Proxies and name_scopes must be merge in orde to not have these kind of problems.

    Here is two tests.

    The first, count over an association proxy. When you call count AssociationCollection#count it call the reflexion with Calculations#count(:all,{})

    
  Tag.first.tagged_posts.count

    But the second use a name_scope.

    
  Tag.first.tagged_posts.containing_the_letter_a.count

    The last one bypass the association proxy, so you call Calculations#count() with any args. In these case it will suppose that there is no association proxy, so it extract column_name from scope(:find)[:select]. As it comes from a proxy, the select is "table_name.*" that obviously is not and SQL valid COUNT.

    Maybe it must be a module for proxies and named_scope.

  • Manfred Stienstra

    Manfred Stienstra April 2nd, 2009 @ 04:33 PM

    • State changed from “new” to “incomplete”
  • Guillermo Álvarez

    Guillermo Álvarez April 2nd, 2009 @ 05:58 PM

    The best thing you can do with these problem is just add (:all) to count. So instend of apply a patch, just be explicit:

    
  Tag.first.tagged_posts.containing_the_letter_a.count

    Must be:

    
  Tag.first.tagged_posts.containing_the_letter_a.count(:all)
  • John Topley

    John Topley April 4th, 2009 @ 12:38 PM

    This bug also gets triggered when using the empty? method, so it's not always possible to add (:all) to count.

  • Guillermo Álvarez

    Guillermo Álvarez April 6th, 2009 @ 03:29 PM

    @John Topley

    There is another thing you can do. Is so simple, but it isn't the best solution.

    Instead of use .empty? Just put .all.empty?

    These isn't clean, doesn't have good performance, but can bypass these kind of rails bugs.

    At least is what i have to do to upgrade some rails apps.

    I prefer have these kind of solutions before start monkey patching.

  • Steven Soroka

    Steven Soroka April 6th, 2009 @ 03:55 PM

    @Guillermo: that's a horrible "solution", and a waste of resources (fetches all records and instantiates all rows as AR objects, just to check if there's any). Even after it's fixed in Rails you'll have to remember to hunt through your code and figure out where all your work-arounds are.

    You're better off getting comfortable patching Rails.

    The CountFix above looks pretty safe (I've used it without problems) and you can always wrap it in Rails version check so you don't have to remember to remove it:

    
  if Rails.version == '2.3.2'
    ...
  end
  • Peter Wagenet

    Peter Wagenet April 7th, 2009 @ 04:07 AM

    Here's a patch. Same as CountFix. It's slightly hackish but it will work until Manfred gets scopes redone.

  • Manfred Stienstra

    Manfred Stienstra April 7th, 2009 @ 12:54 PM

    • Tag changed from “2.3.2, activerecord, bug, calculations, patch, regression, scope, tested, verified” to “2.3.2, activerecord, bug, calculations, patch, regression, scope”
    • Assigned user set to “Pratik”
    • State changed from “incomplete” to “open”

    Peter, did you check if there are other methods like count that might have the same problem with the :select query parameter?

    For other people watching this ticket, this is the time to try to apply the patch on your Rails fork and tell us if it applies and if it solves your problems (:

  • Peter Wagenet

    Peter Wagenet April 7th, 2009 @ 02:27 PM

    I have not checked any non-count methods. If anyone is aware of any that I should take a look at, please let me know.

  • Andrew Bloomgarden

    Andrew Bloomgarden April 10th, 2009 @ 03:17 AM

    That patch is still failing for me, giving me the following SQL error:

    Mysql::Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') AS count_all FROM articles INNER JOIN article_listings ON articles.id =' at line 1: SELECT count(DISTINCT ) AS count_all FROM articles INNER JOIN article_listings ON articles.id = article_listings.article_id WHERE (((articles.headline IN ('Daily Debriefing','Political Debriefing')) AND ((article_listings.issue_id = 2613))) AND ((article_listings.issue_id = 2613)))

    It's from calling #empty? on one named scope called on one has_many :through association.

  • Dan Weinand

    Dan Weinand April 17th, 2009 @ 11:31 PM

    Since this bug has broken pretty significant core functionality and the functionality added by the patch while arguably useful is certainly an edge case, isn't the simplest solution to revert that patch?

    The patch in question didn't appear to get even a single +1, and while it would be nice not to lose that functionality, I would much rather have applications be able to perform the basic functionality without breaking.

    Can we simply call this a poorly vetted patch that should be resubmitted when it deals with these issues and be done with it?

  • grosser

    grosser April 18th, 2009 @ 10:08 AM

    would be great if this could be fixed, i want to upgrade :(

  • Nobuhiro IMAI

    Nobuhiro IMAI April 23rd, 2009 @ 02:58 AM

    Mike Gunderloy suggested me that #2482 is similar problem like this. Would anyone be kind to care about that ticket, too?

  • seanskye

    seanskye April 27th, 2009 @ 07:00 AM

    ok, silly question #547 here: I found the thread, found the final proposed patch. What do I need to do to patch my 2.2.2 rails which is exhibiting this break on a submission of a count() to a mysql db?

    I have the patch, and it appears to be a separate file, so how do I hook it in or where do I place it? Its not a diff file that I run against any particular source file?

    Thanks in advance. s

  • Josh Susser

    Josh Susser May 6th, 2009 @ 05:42 PM

    I put together a monkey patch to workaround the issue until it's fixed.

    http://gist.github.com/107168

  • Will Bryant

    Will Bryant May 11th, 2009 @ 02:39 AM

    seanskye: I think you most likely have a different issue. This regression first appeared in Rails 2.3 RC2; on 2.2.2 it shouldn't be a problem (we use this functionality no problem in a 2.2.2 app).

  • Jacob Gorban

    Jacob Gorban May 12th, 2009 @ 10:08 PM

    • Tag changed from “2.3.2, activerecord, bug, calculations, patch, regression, scope” to “2.2.2, 2.3.2, activerecord, bug, calculations, mysql, patch, regression, scope”

    But there is really a problem with .count on MySQL in 2.2.2. And it's not related to named scopes. I've stumbled on it too. In a database where the models are the following, executing item.orders.count will fail on mysql 5.0.67 (which I use) but runs ok on sqlite.

    
class Order < ActiveRecord::Base
  has_many :lines, :dependent => :destroy
  has_many :items, :through => :lines 
end

class Item < ActiveRecord::Base
  has_many :lines, :dependent => :destroy
  has_many :orders, :through => :lines
end

class Line < ActiveRecord::Base
  belongs_to :order
  belongs_to :item
end

    In the log the following error appears:

    ActionView::TemplateError (Mysql::Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'lines ON orders.id = lines.order_id WHERE ((lines.item_id = 2))' at line 1: SELECT count(*) AS count_all FROM orders INNER JOIN lines ON orders.id = lines.order_id WHERE ((lines.item_id = 2)) ) on line #6 of app/views/admin/index.html.erb:

  • Mislav

    Mislav May 13th, 2009 @ 11:06 AM

    Jacob: "lines" is a reserved word in MySQL. The bug here is that ActiveRecord didn't properly escape table names on JOIN.

  • Duff OMelia

    Duff OMelia May 22nd, 2009 @ 09:42 PM

    Josh - That monkey patch is working wonderfully. Thanks!

  • seamusabshere

    seamusabshere May 27th, 2009 @ 07:11 PM

    I have a lot of named scopes that are ordered by a join:

      named_scope :most_achieved,
    :select => 'tips.*, COUNT(*) AS raw_achievement_count',
    :joins => :achievements,
    :group => 'tips.id',
    :order => 'raw_achievement_count DESC'

    Here's how I changed Josh's monkey patch to support counting these:

      class ActiveRecord::Base
    protected
      def self.construct_count_options_from_args(*args)
        name_and_options = super
        if name_and_options[0].is_a?(String)
          if name_and_options[0].include?(',')
            name_and_options[0] = "DISTINCT #{quoted_table_name}.#{primary_key}"
          elsif name_and_options[0] =~ /\.\*$/
            name_and_options[0] = '*'
          end
        end
        name_and_options
      end
  end

    This way, I get what I expect from

    Tip.most_achieved.count

    because it calls

    SELECT COUNT(DISTINCT tips.id)

    rather than

    SELECT COUNT(*)

  • Will Bryant

    Will Bryant June 1st, 2009 @ 03:37 AM

    As per discussions on rails-core, the original commit introducing the problem has been reverted for 2-3-stable (reverted in 34c3162), so the forthcoming patch release will effectively fix this bug for 2.3. A good solution is required for master (Rails 3), so all the above option are on the table.

    This is a good opportunity to fix up how counts behave with joins etc. too.

  • kazuyoshi tlacaelel

    kazuyoshi tlacaelel June 4th, 2009 @ 06:58 AM

    I think this should default to count just the "memberships"
    table without going into the whole merge thing!

    makes sense?

    ( "memberships" from the first example presented in this page )

  • Thomas Watson

    Thomas Watson June 15th, 2009 @ 07:47 PM

    I don't know the following is releated, but when researching this bug I found that the where-clause created by ActiveRecord changed at some point between 2.1.2 and 2.3.2.

    What in Rails 2.1.2 used to look like this:
    @@@ SQL SELECT count() AS count_all FROM products INNER JOIN product_relations ON products.id = product_relations.child_id WHERE ((products.published = 1) AND ((product_relations.parent_id = 55587668) AND ((product_relations.tp_product_relation_id = 544572937))))

    
Will in 3.2-stable currently look like:
@@@ SQL
SELECT count() AS count_all FROM products INNER JOIN product_relations ON products.id = product_relations.child_id WHERE (((products.published = 1) AND ((product_relations.parent_id = 55587668) AND ((product_relations.tp_product_relation_id = 544572937)))) AND ((product_relations.parent_id = 55587668) AND ((product_relations.tp_product_relation_id = 544572937))))

    As you can see the count-bug is now gone since I've moved from 3.2.3 to 3.2-stable, but for some reason the where-clause is repeated (which it also where on 3.2.3).

    This is an excerpt of the code that gives this issue:
    @@@ Ruby class ProductRelationType < ActiveRecord::Base
    ... end

    class ProductRelation < ActiveRecord::Base
    belongs_to :typ, :foreign_key => 'tp_product_relation_id', :class_name => 'ProductRelationType' belongs_to :child, :foreign_key => 'child_id', :class_name => 'Product' belongs_to :parent, :foreign_key => 'parent_id', :class_name => 'Product' ... end

    class Product < ActiveRecord::Base
    has_many :child_products, :foreign_key => 'parent_id', :class_name => 'ProductRelation' has_many :variants, :through => :child_products, :source => :child, :conditions => { "product_relations.tp_product_relation_id" => ProductRelationType.find_by_label('variant') } named_scope :published, :conditions => { :published => true } ... end

    @product.variants.published.empty?

    
Is this related to this bug?
  • Thomas Watson

    Thomas Watson June 15th, 2009 @ 07:53 PM

    Sorry for the formatting :( Why doesn't Lighthouse have a preview-before-post feature??
    Here goes nothing - sorry if I'm spamming you once again...

    What in Rails 2.1.2 used to look like this:

    SELECT count(*) AS count_all FROM `products` INNER JOIN product_relations ON products.id = product_relations.child_id WHERE ((`products`.`published` = 1) AND ((`product_relations`.parent_id = 55587668) AND ((`product_relations`.`tp_product_relation_id` = 544572937))))

    Will in 3.2-stable currently look like:

    SELECT count(*) AS count_all FROM `products` INNER JOIN `product_relations` ON `products`.id = `product_relations`.child_id WHERE (((`products`.`published` = 1) AND ((`product_relations`.parent_id = 55587668) AND ((`product_relations`.`tp_product_relation_id` = 544572937)))) AND ((`product_relations`.parent_id = 55587668) AND ((`product_relations`.`tp_product_relation_id` = 544572937))))

    As you can see the count-bug is now gone since I've moved from 3.2.3 to 3.2-stable, but for some reason the where-clause is repeated (which it also where on 3.2.3).

    This is an excerpt of the code that gives this issue:

    class ProductRelationType < ActiveRecord::Base
  ...
end

class ProductRelation < ActiveRecord::Base
  belongs_to :typ, :foreign_key => 'tp_product_relation_id', :class_name => 'ProductRelationType'
  belongs_to :child, :foreign_key => 'child_id', :class_name => 'Product'
  belongs_to :parent, :foreign_key => 'parent_id', :class_name => 'Product'
  ...
end

class Product < ActiveRecord::Base
  has_many :child_products, :foreign_key => 'parent_id', :class_name => 'ProductRelation'
  has_many :variants, :through => :child_products, :source => :child, :conditions => { "product_relations.tp_product_relation_id" => ProductRelationType.find_by_label('variant') }
  named_scope :published, :conditions => { :published => true }
  ...
end

@product.variants.published.empty?

    Is this related to this bug?

  • James Le Cuirot

    James Le Cuirot July 27th, 2009 @ 04:45 PM

    I was relying on this feature so I was a little disappointed that it got reverted. Guess you can't please everybody. I have a bunch of customisations/fixes that I occasionally rebase against the stable branch. This time, I had to revert the reversion!

  • Jeremy Kemper

    Jeremy Kemper May 4th, 2010 @ 06:48 PM

    • Milestone changed from “2.x” to “3.x”
  • Will Bryant

    Will Bryant May 26th, 2010 @ 05:49 AM

    So obviously there's been an essentially complete rewrite of this stuff now we're implemented using arel. I manually applied Guillermo's test on master, and it passes as expected. Is there still an issue here, or can we close now?

  • Mislav

    Mislav May 26th, 2010 @ 11:01 AM

    I would only close if there was a passing test committed to both 2-3-stable and master.

  • Will Bryant

    Will Bryant May 26th, 2010 @ 11:22 AM

    OK. I don't think this will ever get fixed for 2.3.

  • Rohit Arondekar

    Rohit Arondekar October 7th, 2010 @ 05:54 AM

    • Importance changed from “” to “Low”

    Any updates here?

  • Jeff Kreeftmeijer

    Jeff Kreeftmeijer November 1st, 2010 @ 05:02 PM

    • Tag cleared.

    Automatic cleanup of spam.

  • Jon Leighton

    Jon Leighton December 22nd, 2010 @ 11:55 AM

    • Milestone cleared.
    • Assigned user changed from “Pratik” to “Aaron Patterson”

    The test passes now, but it wasn't a great test because the scope used did not actually constrain the result of the query. I've written a similar test where the scope does reduce the result, and patched it against 3-0-stable and master. I think we should apply these and be done with it.

  • Jon Leighton

    Jon Leighton December 22nd, 2010 @ 11:57 AM

    • no changes were found...
  • Repository

    Repository December 23rd, 2010 @ 11:31 PM

    • State changed from “open” to “resolved”

    (from [90f55bd93b409897e51a6533b0e3ed5fa284660f]) Test to verify that #2189 (count with has_many :through and a named_scope) is fixed [#2189 state:resolved] https://github.com/rails/rails/commit/90f55bd93b409897e51a6533b0e3e...

  • Santiago Pastorino

    Santiago Pastorino February 12th, 2011 @ 09:58 PM

    • Milestone set to “3.0.5”

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

People watching this ticket

Attachments

Referenced by

Pages