Hi Mark Sorry about the continuing bugs, I managed to find the source of your problem (at least, I'm pretty sure it's the cause), and it's now fixed in 1.3.12, which I've just pushed to GitHub and Gemcutter.
-- Pat On 14/12/2009, at 4:14 AM, Mark Kocera wrote: > Hi, > > Unfortunately it seems 1.3.11 does not yet solve my delta problems. > These are the relevant parts of the problematic model: > > class Event < ActiveRecord::Base > > has_and_belongs_to_many :targets, :order => "name ASC" > > has_one :image, :as => :attachable, :class_name => > 'Asset', :dependent => :destroy > accepts_nested_attributes_for :image > > define_index do > indexes title > > ... > > has targets(:id), :as => :target_ids, :facet => true > has image(:id), :as => :image_id > > set_property :delta => :delayed > end > > Jobs are added when these fields have values, but when they're empty, > the jobs do not get added. (As expected, when I uncomment these lines > jobs are added.) > > I think this should have been fixed in the 1.3.10 release? I'm not > sure how to debug this. > > -- > Mark > > > On Dec 12, 12:30 pm, Al-Faisal El-Dajani <[email protected]> > wrote: >> Works as advertised :). Cheers mate and thanx for an awesome plugin. >> >> >> >> On Sat, Dec 12, 2009 at 1:14 PM, Pat Allan <[email protected]> wrote: >>> Pushed it live a couple of hours ago - give it a spin, would appreciate the >>> confirmation :) >> >>> -- >>> Pat >> >>> On 12/12/2009, at 8:22 PM, Al-Faisal El-Dajani wrote: >> >>>> Cheers mate. Thanx for the excellent response times. >> >>>> Can't wait to see 1.3.11 :) >> >>>> On Sat, Dec 12, 2009 at 10:01 AM, Pat Allan <[email protected]> >>> wrote: >>>> 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]<thinking-sphinx%2Bunsubscribe@ >>> googlegroups.com> >>>>>>>>>> . >>>>>>>>>> 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]<thinking-sphinx%2Bunsubscribe@ >>> googlegroups.com> >>>>>>>> . >>>>>>>> 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]<thinking-sphinx%2Bunsubscribe@ >>> googlegroups.com> >>> . >>>>>>> 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]<thinking-sphinx%2Bunsubscribe@ >>> googlegroups.com> >>> . >>>>>>> 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]<thinking-sphinx%2Bunsubscribe@ >>> googlegroups.com> >>> . >>>>> 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]<thinking-sphinx%2Bunsubscribe@ >>> googlegroups.com> >>> . >>>>> For more options, visit this group at >>> http://groups.google.com/group/thinking-sphinx?hl=en. >> >>>> -- >> >>>> You received this message... >> >> read more ยป > > -- > > 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.
