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 -~----------~----~----~----~------~----~------~--~---
