Thanks Pat! The changes that you made seem to fix both the caching issue and the issue while using the console. While I was playing with the problem I followed a similar approach to yours, but it was at the end of a very long day when I was looking at this issue. I figured it was better to ask you about it since you had just made those changes.
By the way, have you thought any more about multiple connections to Sphinx? Connections to Sphinx are very expensive and I make 4 or 5 searches on a given page sometimes. I have resorted to caching the searches in some places in order to minimize the impact of this, but I am unable to cache everything. I want to coordinate before I go down that rabbit hole. Thanks again for resolving the problem. I will let you know if anything else crops up. DrMark On Aug 8, 12:36 am, Pat Allan <[email protected]> wrote: > Okay, fixed - let me know if the problem still exists :) > > -- > Pat > > On 08/08/2009, at 10:51 AM, Pat Allan wrote: > > > > > > > Hi Mark > > > I think I've figured it out. The difference between Collection and > > Search is that the former was a subclass of Array, the latter acts > > like an array - and stores an array of the results internally. > > However, Search only populates that array when it *needs* to - > > allowing you to chain scopes on (or even edit options, if you like), > > without making multiple calls to searchd. > > > This is why it's not working - when you run it step by step, script/ > > console tries to 'render' temp_a, which invokes inspect, which invokes > > the search call, and so the results are there. However, when you run > > it all at once, that rendering doesn't happen, so the query is not > > made, and therefore the results object is nil. > > > So, how to get around this? I'll make Search#results an actual method > > (instead of an accessor) that populates the array before returning the > > object. Prior to that, add a call to temp_a.first (not assigning it to > > anywhere, just invoking it) before you ask for temp_a .results. I > > realise this is ugly - I'll try to get the patch done today. > > > Sorry for the pain with debugging such an odd problem. > > > Cheers > > > -- > > Pat > > > On 08/08/2009, at 7:35 AM, DrMark wrote: > > >> Ok, this isn't just a Rails caching issue (although that needs to be > >> addressed). Debugging this raised even more bizarre results. > >> Remember, > >> this code worked perfectly prior to Pat's refactoring of > >> TS::Collection => TS::Search > > >> Suppose you have this code: > > >> temp_a = sphinx.search_for_ids(self.q) > >> temp_b = temp_a.results > >> sphinx_ids, sphinx_response = [temp_a, temp_b] > > >> If you check the values after this code has run(via debugger), you > >> will have something like sphinx_ids = [1,2,3,...] but > >> temp_b and sphinx_response will be nil. > > >> However, if you call temp_a.results manually while debugging you will > >> get the hash of result values just like you expect. So basically, if > >> you let the code above run on its own, temp_b = nil. However, if you > >> manually enter the code into console while the code is being > >> debugged, > >> it works properly and returns the hash of results. > > >> Does anyone have any ideas as to what might cause this? I am > >> beginning > >> to think this is a naming issue. The model that I use to setup and > >> run > >> the search is called "Search". > > >> I would greatly appreciate any insight as this isn't making much > >> sense > >> to me at the moment. I am not used to code that works in the console > >> but doesn't work when ran normally. > > >> Thanks, > > >> DrMark > > >> On Aug 7, 4:39 pm, DrMark <[email protected]> wrote: > >>> Aloha everyone, > > >>> I just encountered a very odd bug in TS. First, the code that is > >>> throwing the error has been working perfectly up to this point. The > >>> error started after I upgraded to the latest version of TS where Pat > >>> changed the ThinkingSphinx::Collection code to > >>> ThinkingSphinx::Search. > > >>> The bug happens when you use Rails caching. > > >>> If you have something like this: > > >>> sphinx_ids = Rails.cache.fetch(%Q!#{search_string}!) > >>> { sphinx.search_for_ids q, :with => filters, :order => opts > >>> [:order], :include => opts[:include] } > > >>> This returns a valid ThinkingSphinx::Search object the first time. > >>> On > >>> all subsequent calls, however it returns an Array. Thus, any calls > >>> to > >>> TS methods (like results) will bomb. > > >>> I haven't yet had the time to dig through this to find the cause. > >>> Does > >>> anyone have an idea why Rails.cache.fetch worked fine with the old > >>> TS::Collection code but bombs with the new TS::Search code? > > >>> Thanks! > > >>> DrMark --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
