Определение поля (с типом и т. Д.) Входит в вашу схему, а не в XML обновления.
Сортировка по проанализированному TextField также не является хорошей идеей, так как вы не получите желаемого результата. Если вы хотите выполнить поиск по текстовому полю, выполните сортировку по полю string
или полю с KeywordTokenizer и нижним регистром фильтра (если вы хотите сделать сортировку нечувствительной к регистру).
Правило состоит только в том, что поле id
(или более конкретно - поле uniqueKey, которое может называться как-то иначе, чем id
, но обычно это просто id
) - должно быть присутствует в порядке сортировки. Он не должен быть первым, он просто должен быть там, чтобы сортировка была стабильной.
sort=title asc, id asc
.. идеально подходит для использования cursorMarks для глубокой подкачки.
Для дальнейшего объяснения после вашего комментария
Tokenizer - это то, что сообщает Solr, как разбить входной текст на так называемые «токены». Токен - это то, против чего проводится совпадение. Токенизатор пробельных символов разделит «это текст» на четыре токена: this
, is
, a
и text
. Когда вы ищете только text
или this text
, происходит тот же процесс, затем сравниваются введенные и сохраненные токены, чтобы увидеть, есть ли совпадение.
Сортировка также выполняется с токенами, поэтому, если вы попытаетесь отсортировать текст «cba», он будет разбит на токены на c
, b
и a
- и это не очень полезно для сортировки, поскольку вы ожидаете, что все, начиная с c
, будет отсортировано после b
, но теперь у вас есть три токена для документа, указывающие его действительное значение. Этот процесс обычно дает странные и не интуитивные результаты.
Вместо этого используйте поле string
, поскольку оно сохраняет ввод как один токен. Если вы храните a b c
, весь текст сохраняется как один токен - a b c
и не разбивается на более мелкие фрагменты. Это также означает, что вы получите попадания только в том случае, если входной и сохраненный текст совпадают в точности, поскольку это один большой токен (а именно токены определяют совпадения).
Но так как строковое поле не выполняет ничего , вы можете отсортировать a
и A
как один и тот же символ, вместо того, чтобы сначала сортировать заглавные буквы. Для этого Tokenizer с именем KeywordTokenizer
- KeywordTokenizer не разбивает входной текст на токены, а сохраняет все как один токен. Это кажется бесполезным, так как это то же самое, что и поле string
, но TextField с Tokenizer позволяет вам присоединять фильтры к цепочке анализа, а строковое поле - нет. Таким образом, вы можете добавить LowercaseFilter в цепочку, и, таким образом, токены, сгенерированные для a
и A
, будут одинаковыми - a
в обоих случаях.
Вы настраиваете типы полей и связанную с ними обработку в schema.xml
или через Schema API . Вы можете использовать copyField
, чтобы сообщить Solr «все, что входит в это поле, также должно быть добавлено в это другое поле» - таким образом вы можете сделать так, чтобы ваш контент отображался в нескольких полях и обрабатывался по-разному - один из способов поиска (токенизация на например, пробел) и один способ поиска (вообще не размечен).
Синтаксис, который вы использовали для одного из ваших полей в XML-документах, не предназначен для использования в этом контексте - но при определении поля в schema.xml:
<field name="title" type="text_general" class="solr.TextField" indexed="true" stored="true" required="true" multiValued="false" />
В вашем документе это должно быть просто:
<field name="title">value</field>
Обработка и параметры будут основаны на типе поля, определенного в schema.xml
.