Как Sunspot модифицирует Solr schema.xml? Изменяет ли это вообще?

Сообщите мне, если я ошибаюсь, но я думаю, что solr ожидает только поля, которые уже упоминаются в schema.xml. Итак, если у меня есть поле под названием "title", я должен упомянуть об этом в схеме.

Не упоминается об изменении schema.xml в документации Sunspot. Мне просто интересно, как Sunspot изменяет schema.xml, позволяя вводить настраиваемые поля в индекс.

Я также знаю, что Sunspot использует RSolr для работы. Поэтому, если есть способ изменить схему и перезагрузить данные из базы данных в Solr с помощью RSolr, сообщите мне.

Ответ 1

Как утверждает karmajunkie, Sunspot использует свою стандартную схему. Я расскажу о том, как это работает здесь более подробно.

Схема Solr 101

Для целей этого обсуждения схемы Solr в основном состоят из двух вещей: определения типов и определения полей.

Определение

A type устанавливает тип, указывая его имя, класс Java для этого типа, а в случае некоторых типов (особенно текст) - подчиненный блок XML, настраивающий способ обработки этого типа.

Определение

A field позволяет вам определить имя поля и имя типа значения, содержащегося в этом поле. Это позволяет Solr сопоставлять имя поля в документе с его типом и несколько других параметров и, следовательно, как это значение поля должно обрабатываться в вашем индексе.

Solr также поддерживает определение dynamicField, которое вместо статического имени поля позволяет указать шаблон с глобусом в нем. Входящие поля могут сопоставлять их имена с этими шаблонами, чтобы определить их типы.

Обычная схема Sunspot

Схема Sunspot содержит несколько определений field для внутренних полей, таких как идентификатор и имя модели. Кроме того, Sunspot использует либеральные определения dynamicField для определения соглашений об именах на основе типов.

Это использование соглашений об именах полей позволяет Sunspot определять DSL конфигурации, которая создает сопоставление из вашей модели в XML-документ, готовый к индексированию Solr.

Например, этот простой блок конфигурации в вашей модели...

searchable do
  text :body
end

... будет использоваться Sunspot для создания имени поля body_text. Это имя поля сопоставляется с шаблоном *_text для следующего определения dynamicField в схеме:

<dynamicField name="*_text" type="text" indexed="true" stored="false" multiValued="true"/>

Это отображает любое поле с суффиксом _text в определение Sunspot типа text. Если вы посмотрите на schema.xml Sunspot, вы увидите много других аналогичных соглашений для других типов и параметров. Опция :stored => true, например, обычно добавляет s к суффиксу этого типа (например, _texts).

Изменение схемы Sunspot на практике

В моем опыте с клиентами и моими собственными проектами есть два хороших случая для изменения схемы Sunspot. Во-первых, для внесения изменений в полевые анализаторы text на основе различных функций, которые могут потребоваться вашему приложению. И, во-вторых, для создания новых типов (обычно основанных на текстовом типе) для более мелкозернистого применения анализаторов Solr.

Например, расширение поиска совпадает с "нечетким" поиском может выполняться с совпадениями со специальным текстовым полем, которое также использует лингвистические стебли, или NGrams. Токены в исходном поле text могут использоваться для заполнения орфографической проверки или для повышения точных совпадений. И токены в пользовательских text_ngram или text_en могут служить для расширения результатов поиска, когда более строгое совпадение терпит неудачу.

Sunspot DSL предоставляет одну окончательную функцию для сопоставления полей этим пользовательским полям. После того, как вы настроили type и соответствующие ему определения dynamicField, вы можете использовать параметр Sunspot :as для переопределения генерации имен на основе условных обозначений.

Например, добавив пользовательский тип ngram для вышеописанного, мы могли бы снова обработать тело с помощью NGrams со следующим кодом Ruby:

searchable do
  text :body
  text :body_ngram, :as => 'body_ngram'
end

Ответ 2

Sunspot поставляется со схемой запаса, которая немного настроена на интеграцию с солнечными пятнами, которая придерживается принципа наименьшего удивления для разработчика - например, для запаса solrconfig.xml установлено, что автокоммутил выключен, хотя в процессе производства вы, Я хочу включить это. Схема действительно имеет больше общего с типами, чем поля - см. Ссылку ниже для примера того, как создать новый тип поля. Индексирование поля тривиально, если оно вписывается в один из существующих типов. Например:

class Blog
  searchable do
     text :title
  end
end

И в процессе поиска вы сделаете что-то вроде этого:

class BlogSearch
   def self.search(options={})
     Sunspot.search(Blog) do
       with(:title, options[:title]) if options[:title].present?
     end
   end
end

В wiki для Sunspot есть много дополнительной документации. Здесь приведен пример добавления пользовательского типа для поиска ngram:

https://github.com/outoftime/sunspot/wiki/Wildcard-searching-with-ngrams