Hi Timo ts-datetime-delta doesn't expect nil values for updated_at - so, a patch for that may be worthwhile. As for your other delta scheme, there's nothing like that that I know of that exists to interact with Thinking Sphinx - so if you like that approach, it'd be great to see a gem like ts-datetime-delta or ts-delayed-delta that took the approach you're suggesting.
If you do create it, please do post here so others are aware :) Cheers -- Pat On 22/05/2012, at 5:05 PM, Timo Virkkala wrote: > Hi, > > I'm having some trouble when deleting objects from our production table when > using ts-datetime-delta. I sometimes run into this exception: > > /etc/local/services/admin-prod/railsapp/shared/bundle/ruby/1.9.1/gems/ts-datetime-delta-1.0.2/lib/thinking_sphinx/deltas/datetime_delta.rb:93:in > `toggled': undefined method `>' for nil:NilClass (NoMethodError) > from > /etc/local/services/admin-prod/railsapp/shared/bundle/ruby/1.9.1/gems/thinking-sphinx-2.0.11/lib/thinking_sphinx/active_record/delta.rb:28:in > `block in toggled_delta?' > from > /etc/local/services/admin-prod/railsapp/shared/bundle/ruby/1.9.1/gems/thinking-sphinx-2.0.11/lib/thinking_sphinx/active_record/delta.rb:28:in > `each' > from > /etc/local/services/admin-prod/railsapp/shared/bundle/ruby/1.9.1/gems/thinking-sphinx-2.0.11/lib/thinking_sphinx/active_record/delta.rb:28:in > `any?' > from > /etc/local/services/admin-prod/railsapp/shared/bundle/ruby/1.9.1/gems/thinking-sphinx-2.0.11/lib/thinking_sphinx/active_record/delta.rb:28:in > `toggled_delta?' > from > /etc/local/services/admin-prod/railsapp/shared/bundle/ruby/1.9.1/gems/thinking-sphinx-2.0.11/lib/thinking_sphinx/active_record.rb:352:in > `toggle_deleted' > [...] > > It seems to me that this happens when the updated_at column of the model is > NULL. Is it so that the timestamp columns should never be null, or is this a > bug and ts-datetime-delta should try to prepare for that as well? > > > > I've also been toying with the idea of making a delta scheme for TS that > would work something like the following: > * There would be a table core_indexing_times, which would hold one row for > each indexed table/model > * Full indexing runs would update the timestamp in the core_indexing_times > table and would index rows created/modified before the timestamp > * Delta indexing runs would index rows modified after the timestamp > > Something quite like this was described in the book Introduction to Search > with Sphinx (O'Reilly Media). It seems to me that this would have some > advantages over ts-datetime-delta, such as the removing the need to run the > indexing within some predetermined time period and the need to use index > merging. Does anyone know if something like this has already been implemented > for Thinking Sphinx, or if there are some reasons why this would be a bad > idea? > > > -- > Timo Virkkala > > -- > You received this message because you are subscribed to the Google Groups > "Thinking Sphinx" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/thinking-sphinx/-/VacgLJKQdDgJ. > 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.
