Как Sunspot модифицирует solr schema.xml? Это вообще его модифицирует?

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

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

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

Источник

2 ответа

Решение

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

Solr Schema 101

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

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

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 может служить для расширения результатов поиска, когда более строгое соответствие не удается.

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

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

searchable do
  text :body
  text :body_ngram, :as => 'body_ngram'
end
Источник

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

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

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

Источник
Другие вопросы по тегам