Forum: Rails-core (closed, excessive spam) construct_finder_sql and :select option

Currently, construct_finder_sql gives precedence to :select defined
within the current scope over any passed in option. Unfortunately this
breaks what I thought was a nice clean solution to finding what tags
were applied to a model within a scope, e.g:

module Taggable

   def self.included(base)
     base.class_eval do

       has_many :taggings, :as => :taggable, :dependent => :destroy
       has_many :tags, :through => :taggings

       ...

       def self.tags
         Tag.find_by_sql(construct_finder_sql(
           :select => 'DISTINCT tags.*',
           :joins => { :taggings => :tag }
         ))
       end

     end
   end

end

This works find when not scoped but when scoped it breaks down, e.g:

   Shop.first.products.visible.tags

produces the following sql:

   SELECT DISTINCT products.*
   FROM `products`
   INNER JOIN `manufacturers`
     ON `manufacturers`.id = `products`.manufacturer_id
   INNER JOIN `product_types`
     ON `product_types`.id = `products`.product_type_id
   INNER JOIN `taggings`
     ON `taggings`.taggable_id = `products`.id
     AND `taggings`.taggable_type = 'Product'
   INNER JOIN `tags`
     ON `tags`.id = `taggings`.tag_id
   WHERE ((products.visible = 1
     AND manufacturers.visible = 1
     AND product_types.visible = 1)
     AND (`products`.shop_id = 1))

Ticket #9861 in the Trac database tries to fix the problem for all
options but runs into problems over whether to combine or overwrite
options. I'd like to fix it just for :select - does anyone have any
cases where the scoped :select option should win out over a passed
in :select? Changing the order doesn't break any existing tests.


Andrew