Did it:

ree-1.8.7-2010.01 > comment.body = "Test"
 => "Test"
ree-1.8.7-2010.01 > user.send(:should_toggle_delta?)
 => false
ree-1.8.7-2010.01 > comment.save
 => true
ree-1.8.7-2010.01 > user.send(:should_toggle_delta?)
 => false
ree-1.8.7-2010.01 > user.last_login_at = Time.now.utc
 => Wed Jun 23 02:16:47 UTC 2010
ree-1.8.7-2010.01 > user.send(:should_toggle_delta?)
 => false
ree-1.8.7-2010.01 > user.save
  SQL (0.2ms)   BEGIN
  User Update (19.1ms)   UPDATE `busk_users` SET `updated_at` =
'2010-06-23 02:16:53', `perishable_token` = 'bwFsxBYq88liDd6qCaqY',
`last_login_at` = '2010-06-23 02:16:47' WHERE `id` = 1
[paperclip] Saving attachments.
  SQL (21.0ms)   COMMIT
  Sphinx   Querying: ''
  Sphinx (0.013817s)   Found 1 results
 => true
ree-1.8.7-2010.01 > user.send(:should_toggle_delta?)
 => false

Does it has something to do with that "Sphinx Querying" just after the
save call?


On Jun 22, 5:21 am, Pat Allan <[email protected]> wrote:
> Okay, this is a little odd then.
>
> TS loops through all attributes and fields to check if they've changed. If 
> they're made up of a SQL string (as your full_name field was initially), then 
> they always return true. Same goes for any fields or attributes via 
> associations. Otherwise, TS calls #{column}_changed? on the object, for each 
> column (so your full_name field should be fine).
>
> There's extra logic around attributes, but you don't have any of them. Hence 
> why this is a little confusing.
>
> Can you try making a change to an object that isn't related to the model, and 
> then - before saving - run the following code:
>
>   user.send(:should_toggle_delta?)
>
> What's the boolean value returned?
>
> --
> Pat
>
> On 20/06/2010, at 2:45 PM, Lucas Húngaro wrote:
>
>
>
> > Rails 2.3.5, TS 1.3.16
>
> > On Jun 19, 10:12 pm, Pat Allan <[email protected]> wrote:
> >> What versions of Rails and Thinking Sphinx are you using?
>
> >> --
> >> Pat
>
> >> On 20/06/2010, at 10:00 AM, Lucas Húngaro wrote:
>
> >>> Did that, but the delta job is still enqueued.
>
> >>> Here's the update statement:
>
> >>> UPDATE `users` SET `updated_at` = '2010-06-19 23:50:22',
> >>> `perishable_token` = 'tQ53TKnXFsW05TvjPJg5', `last_login_at` =
> >>> '2010-06-19 15:04:48', `current_login_at` = '2010-06-19 23:50:22',
> >>> `login_count` = 121 WHERE `id` = 36
>
> >>> And the index definition:
>
> >>>  define_index do
> >>>    # fields
> >>>    indexes username, :sortable => true
> >>>    indexes index_email, :sortable => true
> >>>    indexes [first_name, last_name], :as => :full_name, :sortable =>
> >>> true
>
> >>>    # weights
> >>>    set_property :field_weights => {"username" => 100, "full_name" =>
> >>> 100, "index_email" => 50}
>
> >>>    # conditions
> >>>    where "active = 1"
>
> >>>    # delta
> >>>    set_property :delta => :delayed
> >>>  end
>
> >>> On Jun 19, 1:35 pm, Pat Allan <[email protected]> wrote:
> >>>> The issue here is your full_name field. You can merge columns together 
> >>>> automatically:
>
> >>>>  indexes [first_name, last_name], :as => :full_name, :sortable => true
>
> >>>> See if that fixes the unnecessary delta issue.
>
> >>>> Cheers
>
> >>>> --
> >>>> Pat
>
> >>>> On 20/06/2010, at 12:27 AM, Lucas Húngaro wrote:
>
> >>>>> Hi Pat, here's the block:
>
> >>>>> define_index do
> >>>>>   # fields
> >>>>>   indexes username, :sortable => true
> >>>>>   indexes index_email, :sortable => true
> >>>>>   indexes "concat(first_name, ' ', last_name)", :as
> >>>>> => :full_name, :sortable => true
>
> >>>>>   # weights
> >>>>>   set_property :field_weights => {"username" => 100, "full_name" =>
> >>>>> 100, "email" => 50}
>
> >>>>>   # conditions
> >>>>>   where "active = 1"
>
> >>>>>   # delta
> >>>>>   set_property :delta => :delayed
> >>>>> end
>
> >>>>> On Jun 19, 5:45 am, Pat Allan <[email protected]> wrote:
> >>>>>> Hi Lucas
>
> >>>>>> Thinking Sphinx actually tries to be this smart, but it really depends 
> >>>>>> on the index definition - if there are fields or attributes where TS 
> >>>>>> cannot figure out if they've changed (if you're using Rails 2.0 or 
> >>>>>> earlier, or if you have SQL snippets for fields or attributes), then 
> >>>>>> it just assumes the delta update is required.
>
> >>>>>> What does your User model's define_index block look like?
>
> >>>>>> --
> >>>>>> Pat
>
> >>>>>> On 19/06/2010, at 4:14 PM, Lucas Húngaro wrote:
>
> >>>>>>> Hi there.
>
> >>>>>>> I'm using a delta index with delayed_job but a new indexing job is
> >>>>>>> enqueued on every update of a record, no matter if the column is
> >>>>>>> indexed or not. How can I configure TS to update the delta attribute
> >>>>>>> only in case of changes on the indexed columns?
>
> >>>>>>> Example: every time someone signs in, the app increments a column
> >>>>>>> called login_count on the user record. This column is irrelevant for
> >>>>>>> searching purposes and it's not being indexed, but triggers a delta
> >>>>>>> update anyway.
>
> >>>>>>> Thanks.
>
> >>>>>>> --
> >>>>>>> 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 
> > 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.

Reply via email to