Ah, fantastic - I've now got a fix for this pushed to GitHub, and will roll out 1.3.11 soon. What I've done is call the superclass's define_index (unless that superclass is ActiveRecord::Base), so subclasses will then have the appropriate callbacks added.
Sorry this has taken a while to be resolved, and I really appreciate the help in determining the source. -- Pat On 12/12/2009, at 2:00 AM, Al-Faisal El-Dajani wrote: > Hello, > > Sorry for the late reply. I just upgraded to TS 1.3.10, and Sphinx 0.9.9. > Unfortunately, I still have a problem. After the points raised by Andrei > here, I tried to trace the problem, and I believe I figured out where exactly > the problem lies. > > What I did not mention in my earlier explanation of the situation: I have > model Media, which is the parent for models Image and Video in an STI > relationship. The define_index block is defined in the Media model. > > When I create a new Image instance and try to save it, the :define_indexes > before validation callback is invoked. However it immediately returns because > sphinx_index_blocks.nil? is returning true. > > If, however, I call Media.define_indexes from the console, or I try to save > an object from any other model, the call to sphinx_index_blocks.nil? does not > return true, and all sphinx indexes are loaded (including the one defined in > Media), and after that modifying an Image instance adds a job to the delayed > job queue. > > How can I go about fixing this? > > On Thu, Dec 10, 2009 at 5:14 PM, Andrei <[email protected]> wrote: > 1.3.10 has solved the problem, thank you :) > > On Dec 10, 8:51 am, Pat Allan <[email protected]> wrote: > > Can you give 1.3.10 a spin, see if that helps? There was a fix related to > > STI stuff, though not sure it's impacting your issue... > > > > -- > > Pat > > > > On 09/12/2009, at 3:38 AM, Al-Faisal El-Dajani wrote: > > > > > > > > > Hello, > > > > > I removed everything from the define_index block, except for one indexes > > > line the set_property :delta line, and it still misbehaves. However, I > > > copied the define_index block to another model (with appropriate changes > > > of course) and it works just fine. > > > > > What I failed to mention in my first post is that the Image model is the > > > parent in an STI relation. Maybe this has something to do with it? > > > > > On Tue, Dec 8, 2009 at 2:36 AM, Pat Allan <[email protected]> > > > wrote: > > > I can't reproduce this issue locally, so for the models that don't > > > work, can you start commenting out fields and attributes one by one, > > > see if you can determine what line is causing the problem? > > > > > -- > > > Pat > > > > > On 07/12/2009, at 8:35 PM, tomlion wrote: > > > > > > Hello Pat > > > > I met the same problem. > > > > I have also tried to use set_property :delta => true and the delta > > > > index does not work too > > > > I came into script/console and do some type like this: > > > > > > Loading development environment (Rails 2.3.4) > > > >>> Item.methods.collect{|name| name if name =~ /delta/}.uniq > > > > => [nil, "delta_indexed_by_sphinx?", "delta_index_names"] > > > >>> Item.delta_index_names > > > > => ["item_delta"] > > > >>> Item.methods.collect{|name| name if name =~ /delta/}.uniq > > > > => [nil, "index_delta", "delta_indexed_by_sphinx?", "suspended_delta", > > > > "delta_object", "delta_index_names"] > > > > > > is it a lazy-loading issue? > > > > and how i can fix it? > > > > > > On Dec 7, 9:50 am, Pat Allan <[email protected]> wrote: > > > >> It sounds like it could be a lazy-loading issue - what version of > > > >> Rails are you using? Do you have TS installed as a gem or a plugin? > > > >> Does it work when you create a new Image in script/console? > > > > > >> -- > > > >> Pat > > > > > >> On 07/12/2009, at 3:02 AM, Al-Faisal El-Dajani wrote: > > > > > >>> Hello all, > > > > > >>> I just upgraded to Thinking Sphinx 1.3.8, and wanted to use delayed > > > >>> deltas. I set up my define_index as per the documentation and for > > > >>> all > > > >>> models except one it is working just fine. > > > > > >>> For the model that is causing trouble, Image, I have the following > > > >>> define_index block: > > > > > >>> define_index do > > > >>> indexes title > > > >>> indexes caption > > > >>> indexes comments.body, :as => :comment_body > > > >>> indexes tags.name, :as => :tags_names > > > >>> indexes user.username, :as => :username > > > > > >>> where 'moderated = 1' > > > > > >>> has :id, :as => :media_id > > > >>> has user_id > > > >>> has user_views.user_id, :as => :viewed_by > > > >>> has created_at > > > > > >>> set_property :delta => :delayed > > > >>> end > > > > > >>> This is the only model that has an association in the define_index > > > >>> block, and the only model to have a where clause. > > > > > >>> The problem is that modifying any instance of this model does not > > > >>> add > > > >>> a new job into the DB. What I noticed is that after any other model > > > >>> adds a job to the DB this model starts adding jobs, but if this was > > > >>> the first model to be modified it does not add them. > > > >>> Also, the where clause is being ignored when adding new jobs to the > > > >>> DB, but indexing still respects the where clause. Is this the > > > >>> intended > > > >>> behavior? > > > > > >>> I've been using ThinkingSphinx(1.1.6) for a few months now, and it > > > >>> was > > > >>> working fine. When I upgraded to use the delayed delta I started > > > >>> having this problem. Any ideas? > > > > > >>> -- > > > > > >>> 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. > > > > > -- > > > Al-Faisal El-Dajani > > > 10/6 > > > > > -- > > > > > 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. > > > > > > -- > Al-Faisal El-Dajani > 10/6 > > -- > > 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.
