sparky
sparky

Reputation: 112

Sunspot Solr new fields not being indexed

I'm using Sunspot Solr (2.2.7) to search and index an AR model in our app but we're doing something a little differently here. The actual indexable content is stored in a serialized field and I've extended the Sunspot::Adapters::InstanceAdapter and the Sunspot::Adapters::DataAccessor classes to support our use case and registered these adapters.

I define the indexable fields in a config/initializers/sunspot.rb class and an example configuration looks like

Sunspot.setup(Office) do
  time :published_at, trie: true
  integer :id
  text :name
  integer :region_id
  boolean :is_active
  text :address
  text :city
  text :postal_area
  string :postal_code
  string :abbreviation
  integer :person_ids, multiple: true
  string :supported_locales, multiple: true
  string :slug
end

Everything seems to be working on development and on production (Ubuntu 16.04 running Solr 6.4.2).

The problem I'm encountering occurs when I need to add a new field to the index and try to get this change to production. When I add the above line to the Sunspot.setup block

integer :department_ids, multiple: true

to the setup of the Office and re-index, it works on my local machine but when I deploy to production, the new field doesn't get picked up.

I've updated the managed-schema file to include the new field but after I reindex the models, I still do not see the new field when I query for Offices in the query tool.

A sample JSON response for an Office being return looks something like:

{
  "id":"Office 1",
  "type":["Office", "Model"],
  "class_name":["Office"],
  "published_at_dt":"2017-03-22T23:32:22Z",
  "id_i":1,
  "search_name_s":"atlanta",
  "region_id_i":2,
  "is_active_b":true,
  "postal_code_s":"30309",
  "abbreviation_s":"ATL",
  "person_ids_im":[513,
    571,
    1392,
    1722,
    1723],
  "supported_locales_sm":["en"],
  "slug_s":"houston",
  "name_text":["Houston"],
  "address_text":["1 Main Street<br/>Suite 1"],
  "city_text":["Houston"],
  "postal_area_text":["TX"],
  "_version_":1565750688671072256},

}

I've set the log_level to DEBUG but the SOLR update statement doesn't tell me much.

SOLR Request (1.6ms)  [ path=update parameters={} ]

I've tried going into the Rails console on production, manually running

Sunspot.remove_all!(Office)

and then running my index task but the field still doesn't get picked up.

I'm uncertain as to how to debug this issue further.

Is the issue in a change I need to make to managed-schema (there's no schema.xml in my conf directory, just the managed-schema file). The field is defined there and running queries for that field works, but returns 0 results.

Is the issue that the Sunspot.setup code in my initializer requires a full stop of Apache2 and Sunspot in order to pick up my changes? I've tried that as well but didn't see a change.

Or is the issue in that I'm not using the default Rails AR include due to the slightly different use case we have and there are missing methods that I need to implement in my adapter/indexable class?

Any help on this would be greatly appreciated.

Upvotes: 0

Views: 371

Answers (1)

sparky
sparky

Reputation: 112

So after banging around as to why the updated Sunspot config wasn't taking hold, someone suggested I check if spring was running on our production environment. For some reason, it was and it was preventing the new Sunspot config from ever re-initializing. After killing all the running instances of spring and and re-deploying the app, the new changes were picked up and things seem to be working.

Upvotes: 0

Related Questions