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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---