An alternative would be to define a method called sphinx_attributes on your model - TS won't override it, then.
Beyond that, no changes to TS to make this neater just yet, but hopefully it'll happen at some point. -- Pat On 19/02/2010, at 9:00 AM, Eric wrote: > Thanks Steve. > > On Feb 18, 1:01 pm, P Witty <[email protected]> wrote: >> Yeah. Do something like this to process each object that comes back: >> >> results.each do |o| >> class << o; self; end.send(:remove_method, :sphinx_attributes)send >> (:remove_method, :excerpts) >> end >> >> Cheers >> >> -Steve >> >> On Feb 18, 2010, at 11:32 AM, Eric <[email protected]> wrote: >> >> >> >>> Hey Guys- >> >>> I'm running into the same issue. Any updates on a fix? >> >>> Thanks, >>> Eric >> >>> On Jan 31, 10:23 pm, Pat Allan <[email protected]> wrote: >>>> Right, thanks for that Steve. It all makes sense, really... >> >>>> I'll look at changing the sphinx_attributes method (and others) to >>>> be mixed in constantly. >> >>>> -- >>>> Pat >> >>>> On 29/01/2010, at 10:34 AM, Steve H wrote: >> >>>>> Marshal (correctly) won't dump anything with singleton methods. >>>>> This >>>>> is because things with singleton methods can't be properly "re- >>>>> hydrated". Imagine if you dumped an object to JSON. If you >>>>> wanted to >>>>> get it back, you could create a new instance of that object, and >>>>> assign all the values from the values in your JSON string. But if >>>>> you >>>>> have a special method that has been defined on an object, there's no >>>>> way for Marshal to get that method back. So that's why it breaks. >>>>> Take a look at this over-simplified example in IRB: >> >>>>> irb(main):006:0> Marshal.dump Object.new >>>>> => "\004\bo:\vObject\000" >>>>> irb(main):007:0> o = Object.new >>>>> => #<Object:0x10016b4e8> >>>>> irb(main):008:0> def o.foo >>>>> irb(main):009:1> p "foo" >>>>> irb(main):010:1> end >>>>> => nil >>>>> irb(main):011:0> Marshal.dump o >>>>> TypeError: singleton can't be dumped >>>>> from (irb):11:in `dump' >>>>> from (irb):11 >>>>> from :0 >> >>>>> -Steve >> >>>>> On Jan 28, 1:23 am, Pat Allan <[email protected]> wrote: >>>>>> Hi Steve >> >>>>>> The reason I add this on when I get search results back, is >>>>>> because sphinx_attributes is useless at any other point, and I >>>>>> don't like the idea of modifying *all* objects for something that >>>>>> only has use in a single situation. >> >>>>>> Still, maybe it's worth it - it would make the code cleaner, and >>>>>> probably speed up things when search results are populated. I >>>>>> would be interested in trying to figure out why memcache doesn't >>>>>> like it - don't suppose you've found out any of the finer details? >> >>>>>> Cheers >> >>>>>> -- >>>>>> Pat >> >>>>>> On 28/01/2010, at 4:31 AM, Steve H wrote: >> >>>>>>> So... we rely on memcache heavily throughout our site, as I'm sure >>>>>>> many other developers do as well. >> >>>>>>> Adding the sphinx_attributes as a singleton method on the specific >>>>>>> object that is pulled back from the search causes memcache to >>>>>>> break. >> >>>>>>> Frankly, my preferred solution is for the thinking_sphinx gem to >>>>>>> re- >>>>>>> open ActiveRecord (or at least re-open the indexed classes) and >>>>>>> add an >>>>>>> attr_accessor :sphinx_attributes >> >>>>>>> Currently what we're doing is taking some of the stuff out of >>>>>>> sphinx_attributes and putting it into a custom search_results >>>>>>> object >>>>>>> (legacy stuff), then looking our object up again by id. >> >>>>>>> I think the fix I'm going to do (for now) is to remove the >>>>>>> sphinx_attributes method from the object once we're done >>>>>>> initializing >>>>>>> our custom search_results object. But ideally, this wouldn't be >>>>>>> necessary... >> >>>>>>> -Steve >> >>>>>>> -- >>>>>>> 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 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 >>> 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.
