Latest TS gem should take care of that deprecation. Good to know the bug's fixed, too :)
-- Pat On 07/07/2010, at 12:32 PM, rbjarnason wrote: > Hi, > > No problem with debugging :) Thanks for great software. > > And moving from 2.3.5 to 2.3.8 did indeed fix the problem. > > I do get this line when rebuilding but I guess its not serious: > DEPRECATION WARNING: metaclass is deprecated and will be removed from > Rails 2.3 (use singleton_class instead). (called from add_excerpter > at /home/robert/radrails_e_workspace/glg-version-2/vendor/plugins/ > thinking_sphinx/lib/thinking_sphinx/search.rb:297 > > Thanks for you help. > > Warm regards, > Robert > > On Jul 7, 3:46 am, Pat Allan <[email protected]> wrote: >> Hi Robert >> >> Sorry you've had to do all this debugging on your own - but great to know >> you've found the cause. >> >> I think this is actually a Rails/ActiveRecord bug, not a Thinking Sphinx bug >> (I've had someone raise it before) - as TS uses ActiveRecord to generate the >> joins in the sql_query. >> >> So, I'm not sure if it's been fixed, but if you're not using 2.3.8, perhaps >> it's worth upgrading - at least temporarily - to check? Otherwise, I think >> manually editing the config and then using the ts:reindex task (to avoid >> config regeneration) is the only approach. >> >> -- >> Pat >> >> On 07/07/2010, at 4:02 AM, rbjarnason wrote: >> >> >> >>> I can confirm that the problem I've been facing is that >>> the :primary_key column seems to be ignored when building the >>> association SQL. I have a good reason for using both id and uid >>> columns but in my test rig they have similar values causing this >>> unexpected behaviour. >> >>> or this definition: >> >>> belongs_to :project, :primary_key=>"uid", :foreign_key=>"project_uid" >> >>> This is generated: >>> LEFT OUTER JOIN `projects` ON `projects`.id = >>> `project_documents`.project_uid >> >>> Instead of: >>> LEFT OUTER JOIN `projects` ON `projects`.uid = >>> `project_documents`.project_uid >> >>> I can edit the config by hand, but is there any easy way around this >>> in the code? >> >>> Warm regards, >>> Robert >> >>> On Jul 6, 7:37 pm, rbjarnason <[email protected]> wrote: >>>> Hi, >> >>>> I think I've found the problem, its due to the construction of the SQL >>>> query, I'm using :primary_key and :foreign_key in the association and >>>> those don't seem to be picked up correctly in all places. >> >>>> Will post more detail later when I've confirmed that this is the >>>> problem. >> >>>> Warm regards, >>>> Robert >> >>>> On Jul 6, 6:22 pm, rbjarnason <[email protected]> wrote: >> >>>>> Hi, >> >>>>> I'm still trying to work out this problem. >> >>>>> I've added debug traces all over, and I have found something >>>>> interesting in the method add_from_results in facet_search.rb >> >>>>> After: "results.each_with_groupby_and_count { |result, group, count|" >>>>> I do: >>>>> RAILS_DEFAULT_LOGGER.debug("TS: facet_value #{facet_value} result >>>>> #{result} group #{group} count #{count}") >> >>>>> For the two Facets that do not show up as expected when searching the >>>>> group value is 0 while the count is 39 is both places. The group >>>>> value has a large number for all the working Facets. >> >>>>> Any idea what a group value of 0 could signify in this context? >> >>>>> I also confirmed that the Facet search is converting the name of the >>>>> product to a crc32 value to do the Facet.for search and that all looks >>>>> normal compared to the Facet.for that work. >> >>>>> Warm regards, >>>>> Robert >> >>>>> On Jun 30, 4:40 pm, rbjarnason <[email protected]> wrote: >> >>>>>> Hi, >> >>>>>> I've got a strange problem when using Facets. It reports one facet >>>>>> result having, in this example, 39 items but when I use @facets.for it >>>>>> returns an empty array. There are about 20 other facets reported in >>>>>> this category and they all work as expected with @facets.for, its only >>>>>> the facet that has the largest number reported that does not return >>>>>> anything. I can see the items that fit into the category in the main >>>>>> search results list so the data is there. >> >>>>>> Here is the code I use: >>>>>> @facets = ThinkingSphinx.facets params[:search], :all_facets => >>>>>> true, :class_facet => false, :page => params[:page], :order >>>>>> => :created_at, :sort_mode >>>>>> => :desc, :with=>{:search_access_tag=>@search_access_tags << 0} >> >>>>>> And the html: >>>>>> <% @facets.each do |facet, facet_options| %> >>>>>> <h3><%= facet.to_s[0..facet.to_s.length-6].humanize.titleize.pluralize >>>>>> %></h3> >>>>>> <ul> >>>>>> <% facet_options.each do |option, count| %> >>>>>> <% next if option==nil or option=="" %> >>>>>> <li><%= link_to "#{option} (#{count})", :params => >>>>>> {facet => >>>>>> option, :search=>params[:search], :page => 1} %></li> >>>>>> <% end %> >>>>>> </ul> >>>>>> <% end %> >> >>>>>> And then when you click on one of the links it takes you to >>>>>> if params[:project_category_name] >>>>>> @search_results = >>>>>> @facets.for(:project_category_name=>params[:project_category_name].to_s) >>>>>> end >> >>>>>> What is the best approach in debugging this inconsistency in what is >>>>>> reported from the main facets call and the @facets.for returns? Are >>>>>> there any known issues when using :all_facets? >> >>>>>> Warm regards, >>>>>> Robert >> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Thinking Sphinx" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group >>> athttp://groups.google.com/group/thinking-sphinx?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Thinking Sphinx" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/thinking-sphinx?hl=en. > -- You received this message because you are subscribed to the Google Groups "Thinking Sphinx" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/thinking-sphinx?hl=en.
