17

I have a model which deploys a delayed job that updates some of its attributes. The model is declared "searchable"...

searchable do
  text :content, :stored => true  
end

... which I thought would re-index after a save. On testing, this doesn't seem to be the case. If I run: rake sunspot:reindex, then everything works as expected. What could be causing this issue?

Abram
  • 39,950
  • 26
  • 134
  • 184
Newy
  • 38,977
  • 9
  • 43
  • 59
  • could you add some better keywords to this questions so it gets better reach? – Danny Dec 08 '10 at 22:02
  • I don't think this question is very well phrased, nor are the solutions. For one, the user obviously is using `sunspot_rails`, not just 'sunspot'. For two, the Answers suggested discuss things that are moot because of sunspot_rails's default sunspot settings. – nessur Jun 27 '11 at 21:22
  • I'm also interested in a rspec test for model commits, to make sure it's working. – Anna Billstrom Apr 02 '13 at 20:19
  • I'm having this problem as well. It worked in development, but it's not working in production with delayed_jobes. – Alfo Apr 24 '13 at 19:35

3 Answers3

20

As mentioned by Jason, you can call Sunspot.commit_if_dirty to issue a commit from your client.

From the server configuration side, another approach would be to set the autoCommit property in your solrconfig.xml to automatically issue commits when there have been changes made to your index. A maxTime of 60000 ms (one minute) should suffice for most sites.

Using autoCommit is probably the wiser choice in production applications, where a high volume of commits can easily impact your Solr server's performance. In fact, it's a good practice with Sunspot to disable its auto_commit_after_request option when your site starts getting a decent amount of updates.

Lastly, autoCommit has the advantage of being able to set it and forget it.

At Websolr, our default is to ignore client-issued commits in favor of autoCommit.

Nick Zadrozny
  • 7,906
  • 33
  • 38
  • 2
    the question is actually about the `sunspot_rails` plugin, not vanilla sunspot. – nessur Jun 27 '11 at 21:23
  • 4
    Hi nessur, not sure what point you're trying to make here. sunspot_rails is little more than a light wrapper to hook Sunspot into Rails models and controllers. Besides which, this question boils down to issuing commits, which you can issue from `curl` for all the client matters. – Nick Zadrozny Jul 10 '11 at 00:17
  • The question asks about 'auto-commit' functionality, and this very 'light wrapper' adds to Sunspots' base functionality, so it's all too relevant which gem a user has installed. Undocumented features make the world go round, and the average novice might be intrigued to learn that sunsport_rails installs a controller hook that by default commits any pending changes to the solr index. – nessur Jul 11 '11 at 18:55
8

The index will only reflect changes after Sunspot.commit is called. This happens automatically when you run rake sunspot:reindex.

Sunspot's Rails plugin also has a auto_commit_after_request config option which will call Sunspot.commit_if_dirty after every request but this will not be triggered by your background processes.

Your best bet is to call Sunspot.commit_if_dirty after as the last thing in your delayed job.

Jason Weathered
  • 7,762
  • 2
  • 41
  • 37
  • 2
    (repeating myself) The question is actually about the `sunspot_rails` plugin, not vanilla sunspot. – nessur Jun 27 '11 at 21:24
  • why best bet is ```Sunspot.commit_if_dirty``` better than ```Sunspot.commit``` ? – Changwoo Rhee Jan 01 '22 at 09:00
  • 1
    If I recall correctly, `Sunspot.commit` will always flushes to disk and starts a new searcher instance even when nothing has changed. `Sunspot.commit_if_dirty` will only do that work if a change has been made. – Jason Weathered Jan 02 '22 at 23:33
6

I had the exact same problem as you - when I was testing my search functionality sunspot would never issue a commit to solr. If I manually call Sunspot.commit everything works. I fiddled around with auto_commit_after_request, but this is true by default so it shouldn't make a different.

So after some more investigation I found that Sunspot won't issue a commit automatically unless the change is made in the context of a web request. If you're doing a change from a test or a background job you have to call Sunspot.commit manually.

Jaco Pretorius
  • 24,380
  • 11
  • 62
  • 94