Analiza wymagań

Chcemy dodać dwie nowe funkcjonalności:

1. Zawężanie wyników wyszukiwania w taki sposób, aby możliwe było wyświetlenie tylko tych aut, które są położone nie dalej niż x kilometrów od określonego miejsca, gdzie x = 50,100,200,500,1000 km.
2. Sortowanie wyników wyszukiwania po odległości pomiędzy danym punktem, a lokalizacją auta z danego ogłoszenia.

W celu realizacji powyższych zadań, skorzystamy z funkcjonalności solr zwanej „Spatial Search”, która dostępna jest od wersji 3.1. Zmiany, które będziemy musieli wprowadzić, dotyczyć będą modyfikacji pliku schema.xml oraz danych wejściowych, do których dodamy informację o położeniu geograficznym każdego z aut. Na końcu zostanie nam już tylko odpowiednie złożenie zapytań.

Zmiany w schema.xml

1. Definicja nowych typów pól:
   • pierwsza definicja to nic innego jak kolejny typ liczbowy – double:

   <fieldType name="tdouble" precisionStep="8" omitNorms="true" positionIncrementGap="0"/>

   • druga definicja zaś wykorzystuje specjalną klasę „solr.LatLonType”, która pozwoli nam na zaindeksowanie danych geograficznych wykorzystując pole dynamiczne o suffixie „_coordinate”:

   <fieldType name="location" subFieldSuffix="_coordinate"/>

2. Definicja  nowych pól:
   • pole, które będzie wykorzystywane do gromadzenia informacji o nazwie miejscowości, z którego pochodzi auto:

   <field name="city" type="string" indexed="true" stored="true" />

   • pole „loc” posłuży nam do zaindeksowania danych lokalizacyjnych:

   <field name="loc" type="location" indexed="true" stored="false"/>

   • pole dynamiczne będzie wykorzystywane wewnętrznie do gromadzenia informacji, które wprowadzimy do pola „loc”:

   <dynamicField name="*_coordinate"  type="tdouble" indexed="true" stored="false"/>

Analiza danych wejściowych

W celu prezentacji sposobu modyfikacji nowych danych, weźmy próbkę 5-ciu ogłoszeń z miast:

1. Koszalin
   • szerokość geograficzna: 54.12
   • długość geograficzna: 16.11
2. Białystok
   • szerokość geograficzna: 53.08
   • długość geograficzna: 23.09
3. Szczecin
   • szerokość geograficzna: 53.25
   • długość geograficzna: 14.35
4. Gdańsk
   • szerokość geograficzna: 54.21
   • długość geograficzna: 18.40
5. Warszawa
   • szerokość geograficzna: 52.15
   • długość geograficzna: 21.00

Dane lokalizacyjne wprowadzamy do pola „loc” wpisując szerokość geograficzną danego miasta oraz po przecinku jego długość. Nasze dane mogą wyglądać zatem tak:

<add>
   <doc>
      <field name="id">1</field>
      <field name="make">Audi</field>
      <field name="model">80</field>
      <field name="year">2008</field>
      <field name="price">9774</field>
      <field name="engine_size">2000</field>
      <field name="mileage">92467</field>
      <field name="colour">green</field>
      <field name="damaged">false</field>
      <field name="city">Koszalin</field>
      <field name="loc">54.12,16.11</field>
   </doc>
   <doc>
      <field name="id">2</field>
      <field name="make">Audi</field>
      <field name="model">A8</field>
      <field name="year">2009</field>
      <field name="price">9078</field>
      <field name="engine_size">1000</field>
      <field name="mileage">31369</field>
      <field name="colour">black</field>
      <field name="damaged">false</field>
      <field name="city">Białystok</field>
      <field name="loc">53.08,23.09</field>
   </doc>
   <doc>
      <field name="id">3</field>
      <field name="make">Audi</field>
      <field name="model">TT</field>
      <field name="year">1997</field>
      <field name="price">1109</field>
      <field name="engine_size">1299</field>
      <field name="mileage">116987</field>
      <field name="colour">silver</field>
      <field name="damaged">true</field>
      <field name="city">Szczecin</field>
      <field name="loc">53.25,14.35</field>
   </doc>
   <doc>
      <field name="id">4</field>
      <field name="make">BMW</field>
      <field name="model">Seria 7</field>
      <field name="year">2007</field>
      <field name="price">140000</field>
      <field name="engine_size">3000</field>
      <field name="mileage">418000</field>
      <field name="colour">green</field>
      <field name="damaged">false</field>
      <field name="city">Gdańsk</field>
      <field name="loc">54.21,18.40</field>
   </doc>
   <doc>
      <field name="id">5</field>
      <field name="make">Chevrolet</field>
      <field name="model">TrailBlazer</field>
      <field name="year">2007</field>
      <field name="price">140000</field>
      <field name="engine_size">3000</field>
      <field name="mileage">418000</field>
      <field name="colour">green</field>
      <field name="damaged">false</field>
      <field name="city">Warszawa</field>
      <field name="loc">52.15,21.00</field>
   </doc>
</add>

Tworzymy zapytania

Dane lokalizacyjne mamy w indeksie, zatem zostało nam już tylko złożyć odpowiednie zapytania, które zrealizują nasze nowe funkcjonalności. Załóżmy, że będziemy wyszukiwać ogłoszenia znajdując się w mieście Białystok, które jest położone w odległości ok. 200 km od miasta Warszawa, ok. 400 km od miasta Gdańsk, ok. 550 km od miasta Koszalin oraz ok. 650 km od miasta Szczecin.

W celu realizacji punktu 1 z analizy wymagań, dodajemy do żądania nowe zapytanie filtrujące:

...&fq={!geofilt sfield=loc}&pt=53.08,23.09&d=50

gdzie:

• sfield – nazwa pola, do którego wprowadzaliśmy nasze dane lokalizacyjne.
• pt – współrzędne punktu startowego, w naszym wypadku są to współrzędne miasta Białystok.
• d – dystans o jaki chcemy zawęzić wyniki wyszukiwania. Podstawiając kolejno wartości 50,100,200,500,1000 możemy zrealizować nasze wymagania.

Przykład:

1. Zapytanie:

   q=*:*&fq={!geofilt sfield=loc}&pt=53.08,23.09&d=200

2. Wyniki wyszukiwania:

<result name="response" numFound="2" start="0">
   <doc>
      <str name="city">Białystok</str>
      <str name="colour">black</str>
      <bool name="damaged">false</bool>
      <int name="engine_size">1000</int>
      <str name="id">2</str>
      <str name="make">Audi</str>
      <int name="mileage">31369</int>
      <str name="model">A8</str>
      <float name="price">9078.0</float>
      <int name="year">2009</int>
   </doc>
   <doc>
      <str name="city">Warszawa</str>
      <str name="colour">green</str>
      <bool name="damaged">false</bool>
      <int name="engine_size">3000</int>
      <str name="id">5</str>
      <str name="make">Chevrolet </str>
      <int name="mileage">418000</int>
      <str name="model">TrailBlazer</str>
      <float name="price">140000.0</float>
      <int name="year">2007</int>
   </doc>
</result>

Świetnie, w wynikach nie mamy ogłoszeń z miast Koszalin, Gdańsk oraz Szczecin, gdyż te miasta leżą w odległości ponad 200 km od miasta Białystok.

W celu realizacji punktu 2 z analizy wymagań, wykorzystamy możliwość sortowania wyników wyszukiwania z użyciem funkcji geodist. Tworzymy następujące zapytanie:

...&sfield=loc&pt=53.08,23.09&sort=geodist()+desc

Przykład sortowania wyników wyszukiwania po odległości, rozpoczynając od miasta Białystok:

1. Zapytanie:

   q=*:*&sfield=loc&pt=53.08,23.09&sort=geodist()+asc

2. Wyniki wyszukiwania:

<result name="response" numFound="5" start="0">
   <doc>
      <str name="city">Białystok</str>
      <str name="colour">black</str>
      <bool name="damaged">false</bool>
      <int name="engine_size">1000</int>
      <str name="id">2</str>
      <str name="make">Audi</str>
      <int name="mileage">31369</int>
      <str name="model">A8</str>
      <float name="price">9078.0</float>
      <int name="year">2009</int>
   </doc>
   <doc>
      <str name="city">Warszawa</str>
      <str name="colour">green</str>
      <bool name="damaged">false</bool>
      <int name="engine_size">3000</int>
      <str name="id">5</str>
      <str name="make">Chevrolet </str>
      <int name="mileage">418000</int>
      <str name="model">TrailBlazer</str>
      <float name="price">140000.0</float>
      <int name="year">2007</int>
   </doc>
   <doc>
      <str name="city">Gdańsk</str>
      <str name="colour">green</str>
      <bool name="damaged">false</bool>
      <int name="engine_size">3000</int>
      <str name="id">4</str>
      <str name="make">BMW</str>
      <int name="mileage">418000</int>
      <str name="model">Seria 7</str>
      <float name="price">140000.0</float>
      <int name="year">2007</int>
   </doc>
   <doc>
      <str name="city">Koszalin</str>
      <str name="colour">green</str>
      <bool name="damaged">false</bool>
      <int name="engine_size">2000</int>
      <str name="id">1</str>
      <str name="make">Audi</str>
      <int name="mileage">92467</int>
      <str name="model">80</str>
      <float name="price">9774.0</float>
      <int name="year">2008</int>
   </doc>
   <doc>
      <str name="city">Szczecin</str>
      <str name="colour">silver</str>
      <bool name="damaged">true</bool>
      <int name="engine_size">1299</int>
      <str name="id">3</str>
      <str name="make">Audi</str>
      <int name="mileage">116987</int>
      <str name="model">TT</str>
      <float name="price">1109.0</float>
      <int name="year">1997</int>
   </doc>
</result>

Zgadza się! Wymagania zostały zrealizowane.

Podsumowanie

Po raz kolejny udało nam się sprostać oczekiwaniom naszych klientów. Tym razem dodaliśmy funkcjonalności związane z lokalizacją geograficzną aut, które pozwolą użytkownikom na zawężanie oraz sortowanie wyników wyszukiwania wykorzystując odległości geograficzne. Pełen sukces.

Analiza wymagań

W celu dokonania analizy danych, które wchodzą w skład pola, po którym wyszukujemy, weźmy następującą próbkę, na której oprzemy naszą konfigurację:

• Marka: Audi
  Modele: 80, 90, A6, A8, TT

• Marka: BMW
  Modele: M3, M5, Seria 7, Seria 8, X1, X3

• Marka: Chevrolet
  Modele: TrailBlazer

• Marka: Citroen
  Modele: C-Crosser, C3 Pluriel, C4 Picasso

• Marka: Ford
  Modele: C-MAX, S-MAX

• Marka: Honda
  Modele: Accord, CR-V, FR-V, HR-V

• Marka: Kia
  Modele: Cee’d

• Marka: Suzuki
  Modele: Alto/Maruti

Nazwy marek są prostymi słowami, z którymi aktualna konfiguracja (WhitespaceTokenizer + LowerCaseFilter) poradzi sobie bez problemu. Problem pojawia się przy modelach aut, które zawierają dodatkowe znaki oraz separatory, które często ignorujemy przy wyszukiwaniu. Pogrupujmy sobie powyższą próbkę ze względu na charakterystykę danych:

1. Nazwy modeli, które nie wymagają dodatkowych filtrów i obecna konfiguracja jest wystarczająca – 80, 90, TT, Seria 7, Seria 8, Accord
2. Nazwy modeli, których nazwy składają się z cyfr i liter, których to rozdzielenie jest pożądane – A6, A8, M3, M5, X1, X3, C3 Pluriel, C4 Picasso. Chcielibyśmy móc wyszukiwać powyższe modele wpisując tylko literę lub tylko cyfrę, ale również wpisując całą nazwę modelu.
3. Modele, które mają zmianę wielkości znaków w nazwie – TrailBlazer. Chcielibyśmy znaleźć taki model wpisując „trail”, „blazer”, „trailBlazer”, „trailblazer”.
4. Nazwy modeli, które zawierają separatory, które chcemy ignorować (wpisując nazwę modelu jako pełny wyraz – uwzględniając separator lub nie – oraz po częściach nazwy modelu, które taki separator generuje) – C-Crosser, C-MAX, S-MAX, CR-V, FR-V, HR-V, Alto/Maruti.
   Przykład: chcielibyśmy znaleźć ogłoszenie z modelem „C-MAX” wpisująć frazy „c”, „max”, „c-max” „cmax”.
5. Celowo w punkcie 4 pominąłem model „Cee’d”. Ten model przy wyszukiwaniu chcielibyśmy traktować trochę inaczej, a mianowicie uniemożliwić znalezienie ogłoszenia przy wpisaniu „cee” lub „d”. Traktujemy nazwę „Cee’d” tylko i wyłącznie jako jeden wyraz, czyli realizujemy wyszukiwanie tylko dla przypadków „cee’d” oraz „ceed”.

Konfiguracja WordDelimiterFilter

Na podstawie opisanej charakterystyki dobierzmy takie wartości atrybutów filtra WordDelimiterFilter, aby wszystkie powyższe wymagania zostały spełnione:

1. WordDelimiterFilter jest w tym wypadku zbędny, do realizacji wymagań z pkt 1 wystarczy WhitespaceTokenizer + LowerCaseFilter.
2. W celu realizacji wymagań z pkt 2 należy zadbać o odpowiednie ustawienie następujących atrybutów:
   • generateWordParts=”1″ – wartość musi być ustawiona na „1”, jeżeli chcemy mieć możliwość generowania części słów
   • generateNumberParts=”1″ – wartość musi być ustawiona na „1”, jeżeli chcemy mieć możliwość generowania części liczbowych
   • splitOnNumerics=”1″ – wartość musi być ustawiona na „1”, jeżeli chcemy mieć możliwość rozdzielania literek od liczb
3. W celu realizacji wymagań z pkt 3, musimy ustawić następujące atrybuty:
   • generateWordParts=”1″
   • splitOnCaseChange=”1″ – wartość musi być ustawiona na „1”, jeżeli chcemy mieć możliwość generowania części słów przy przejściu z dużej litery na małą i odwrotnie
4. W celu realizacji wymagań z pkt 4, ustawiamy następujące atrybuty:
   • generateWordParts=”1″
   • catenateWords=”1″ – wartość musi być ustawiona na „1”, abyśmy mogli dodatkowo ignorować separatory, poprzez łączenie wyrazów, które są takim separatorem rozdzielone

Zatem konfiguracja naszego filtra wygląda następująco:

<filter class="solr.WordDelimiterFilterFactory"
 splitOnNumerics="1"
 splitOnNumerics="1"
 generateWordParts="1"
 generateNumberParts="1"
 catenateWords="1"
/>

Dodatkowo okazuje się, że domyślna wartość atrybutów „splitOnNumerics” oraz „splitOnNumerics” to właśnie „1”. Pozostałe atrybuty, których nie wykorzystujemy (poza „stemEnglishPossessive”), mają domyślną wartość na „0”. Konfiguracja naszego filtra zatem upraszcza się do następującej postaci:

<filter class="solr.WordDelimiterFilterFactory"
 generateWordParts="1"
 generateNumberParts="1"
 catenateWords="1"
 stemEnglishPossessive="0"
/>

Co zrobić z punktem nr. 5 naszej charakterystyki danych? Ustaliliśmy, że nie chcielibyśmy dla tego przypadku traktować znaku ” ’ ” jako separatora, a tak właśnie by się stało przy powyższej konfiguracji. Może zatem użyć w filtrze opcji, która zachowa to słowo w stanie niezmienionym, czyli wykorzystać atrybut protected=”protwords.txt” i dodać słowo „Cee’d” do pliku protwords.txt? No tak, ale co z faktem, że chcemy móc wyszukać taki dokument, przy wpisaniu frazy „ceed” ? Najlepiej by było zająć się tym przypadkiem w oddzielnym filtrze, a do filtra WordDelimiterFilter wprowadzić wartość, której ten filtr nie będzie musiał już analizować.

Konfiguracja PatternReplaceFilter

Filtr PatternReplaceFilter zastosujemy przed filtrem WordDelimiterFilter. Za pomocą PatternReplaceFilter będziemy mogli po prostu wyciąć znak „'” z nazwy tego specyficznego modelu, zastępując go pustym znakiem. W ten sposób, do filtra WordDelimiterFilter trafi nam nazwa „Ceed”, która przy obecnej konfiguracji nie zastosuje na takiej wartości żadnej modyfikacji. Filtry będą miały taką samą konfigurację przy indeksowaniu jak i przy wyszukiwaniu, zatem użytkownik będzie w stanie znaleźć ogłoszenie z marką „Cee’d” przy wpisaniu frazy „cee’d” jak i „ceed”:

<filter class="solr.PatternReplaceFilterFactory" pattern="'" replacement="" replace="all" />

Wizualizacja działania nowej konfiguracji typu pola „text”

Podsumowując, nasz typ „text” zmienił się następująco:

<fieldType name="text" positionIncrementGap="100">
 <analyzer>
  <tokenizer class="solr.WhitespaceTokenizerFactory"/>
   <filter class="solr.PatternReplaceFilterFactory" pattern="'" replacement="" replace="all" />
   <filter class="solr.WordDelimiterFilterFactory"
    generateWordParts="1"
    generateNumberParts="1"
    catenateWords="1"
    stemEnglishPossessive="0"
  />
  <filter class="solr.LowerCaseFilterFactory"/>
 </analyzer>
</fieldType>

Wykorzystajmy panel administracyjny solr, aby zobaczyć na przykładzie każdego z punktów, czy konfigurując nasz typ tak jak powyżej, otrzymamy to, czego oczekujemy:

1. (Model: „80”) Tak jak oczekiwaliśmy, wprowadzone filtry nie mają wpływu na dane charakterystyczne dla punktu 1.
2. (Model: „A8”) WordDelimiterFilter rozdzielił nam liczbę od wyrazu.
3. (Model: „TrailBlazer”)WordDelimiterFilter rozdzielił nam „trail” od „Blazer”. Dodatkowo mamy możliwość wyszukiwania po „trailblazer”. Super.
4. (Model: „CR-V”) WordDelimiterFilter rozdzielił nam wyraz po separatorze (w tym wypadku „-„). Dodatkowo mamy możliwość wyszukiwania po nazwie modelu nie uwzględniając separatora („crv”).
5. (Model: „Cee’d”) PatternReplaceFilter zamienił nam „Cee’d” na „Ceed” a WordDelimiterFilter zachował tę wartość. O to nam chodziło.

Podsumowanie

W drugiej części naszego cyklu użyliśmy dwóch nowych filtrów w celu poprawy jakości wyników wyszukiwania. Na przykładzie naszych „samochodowych” danych omówiliśmy użycie WordDelimiterFilter oraz PatternReplaceFilter. Poprawka wprowadzona, klient usatysfakcjonowany … ale na jak długo ?

Analiza wymagań

Wyobraźmy sobie, że chcemy wykorzystać silnik solr w celu dodania wyszukiwarki ogłoszeń samochodowych do naszego serwisu. Serwis nasz jest w tym momencie dosyć prymitywny i przetrzymuje podstawowe informacje opisujące właściwości każdego wystawionego na sprzedaż samochodu:

• marka
• model
• rok produkcji
• cena
• pojemność
• przebieg
• kolor
• czy uszkodzony

Chcielibyśmy w tym momencie zaprojektować najprostszy plik konfiguracyjny, który pomoże odpowiednio zaindeksować dane z powyższych pól. Zanim jednak przystąpimy do rzeźbienia pliku schema.xml, odpowiedzmy sobie na siedem podstawowych pytań, dotyczących każdego z tych pól:

1. Jaki typ ?

Ustalamy typ każdego pola:

• marka – pole tekstowe
• model – pole tekstowe
• rok produkcji – pole liczbowe
• cena – pole liczbowe, zmiennoprzecinkowe
• pojemność – pole liczbowe
• przebieg – pole liczbowe
• kolor – pole tekstowe
• czy uszkodzony – pole logiczne

Co nam to mówi ?

Będziemy potrzebowali definicji typów: string, boolean, int, float.

2. Czy po polu ma się odbywać wyszukiwanie ?

Ustalamy, z których pól będą wykorzystywane informacje, w celu znalezienia odpowiednich ogłoszeń samochodowych. W naszym serwisie będą to 3 pola: marka, model oraz rok produkcji.

Co nam to mówi ?

Pewnie będziemy potrzebowali kolejnego typu pola, który będzie poddawany działaniu różnych filtrów, zwiększających nasze szanse znalezienia interesującego nas dokumentu. Stworzymy sobie dodatkowe pole tego typu, po którym będziemy wyszukiwać i wrzucimy tam dane z wszystkich 3 powyższych pól.

3. Czy sortowalne lub grupowalne ?

Serwis nasz przewiduje sortowanie wyników wyszukiwania po polach: model, rok produkcji, cena oraz przebieg. Chcielibyśmy również móc grupować wyniki wyszukiwania (faceting) po polach marka, model, rok produkcji oraz kolor.

Co nam to mówi ?

Pola tekstowe, po których sortujemy lub grupujemy nie powinny być poddawane działaniu filtrów, które mogą nam rozdzielić na tokeny wartości w tych polach. Zależy nam jednak na tym, aby wszystkie wartości były zapisane małymi literami, tak aby wielkość liter nie wpływała na sortowanie czy też grupowanie. Będzie trzeba stworzyć nowy typ pola, który nam to umożliwi.

4. Czy wykorzystywane przy filtrowaniu ?

Na stronie wyszukiwania ogłoszeń chcemy mieć możliwość zawężenia wyników wyszukiwania, poprzez ustawianie zakresów na polach: rok produkcji, cena, pojemność oraz przebieg.

Co nam to mówi ?

Dobierzmy zatem takie typy dla tych pól, aby filtrowanie po zakresach było jak najbardziej wydajne.

5. Czy zostały mi pola, które nie zostały wymienione w punktach 2, 3 lub 4 ?

Okazuje się, że na polu „czy wymagane” nie będziemy przeprowadzać żadnych „operacji”.

Co nam to mówi ?

Ustawiamy atrybut „indexed” dla takiego pola na wartość false.

6.Czy wymagane ?

W naszym serwisie zakładamy, że polami wymaganymi dla każdego ogłoszenia będą pola marka, model oraz rok produkcji. Nie chcemy mieć dokumentów, które nie mają zdefiniowanych co najmniej tych trzech pól.

Co nam to mówi ?

Przy definiowaniu tych pól musimy pamiętać o ustawieniu wartości atrybutu „required” na true.

7. Czy wartości pól mają być pobierane z indeksu w oryginalnym stanie?

Informację ze wszystkich pól chcielibyśmy wyciągnąć bezpośrednio z wyników wyszukiwania i zaprezentować klientowi serwisu.

Co nam to mówi ?

Przy definiowaniu tych pól musimy pamiętać o ustawieniu wartości atrybutu „stored” na true.

Dodajmy definicje typów pól

Odpowiedzieliśmy już sobie na nasze niezbędne pytanie, wyciągnęliśmy wnioski, więc czas wprowadzić je w życie. Dodajmy do schemy typy pól:

Dodajemy zwykły typ string, który nie jest poddawany żadnej analizie, przyda się np. jako typ dla pola reprezentującego unikalny identyfikator dokumentu.

<fieldType name="string" sortMissingLast="true" omitNorms="true"/>

Dodajemy typ boolean.

<fieldType name="boolean" sortMissingLast="true" omitNorms="true"/>

Dodajemy typy dla pól liczbowych. Pamiętamy, że zależy nam na typach, które zagwarantują nam szybsze wykonywanie zapytań po zakresach. Skorzystajmy zatem z typów tint oraz tfloat:

<fieldType name="tint" precisionStep="8" omitNorms="true" positionIncrementGap="0"/>
<fieldType name="tfloat" precisionStep="8" omitNorms="true" positionIncrementGap="0"/>

Stwórzmy teraz typ tekstowy, który będzie wykorzystywany przez pole zbiorcze po którym będziemy wyszukiwać. Załóżmy prosty typ, który rozdzieli nam wszystkie tokeny po białych znakach, po czym zamieni wszystkie litery na małe.

<fieldType name="text" positionIncrementGap="100">
  <analyzer>
    <tokenizer class="solr.WhitespaceTokenizerFactory"/>
    <filter class="solr.LowerCaseFilterFactory"/>
  </analyzer>
</fieldType>

Potrzebujemy jeszcze typu dla pól, które będą sortowalne/grupowalne:

<fieldType name="lowercase" positionIncrementGap="100">
  <analyzer>
    <tokenizer class="solr.KeywordTokenizerFactory"/>
    <filter class="solr.LowerCaseFilterFactory" />
    <filter class="solr.TrimFilterFactory" />
  </analyzer>
</fieldType>

KeywordTokenizer tak naprawdę nie tokenizuje wartości którą dostaje na wejściu, czyli niezmieniona wartość zostanie poddana działaniu filtra LowerCaseFilterFactory po czym filtr TrimFilterFactory zadba o to, aby zostały usunięte wszelkie białe znaki, znajdujące się na początku lub na końcu wartości.

Dodajmy definicje pól

Identyfikator dokumentu:

<field name="id" type="string" indexed="true" stored="true" required="true" />

Marka oraz model:

<field name="make" type="text" indexed="false" stored="true" required="true" />
<field name="model" type="text" indexed="false" stored="true" required="true" />

Nasuwa się pytanie, dlaczego atrybuty indexed dla pól marka oraz model są ustawione na false? Przecież są to pola, które wykorzystywane są przy wyszukiwaniu, sortowaniu i grupowaniu. Zgadza się. Jednakże w celach wyszukiwania przekopiujemy wartości z tych pól do pola zbiorczego, a w celach sortowania/grupowania przekopiujemy wartości z tych pól do pól o typie „lowercase”.
Pola, do których będziemy kopiować wartości marek oraz modeli samochodów, a które to będą wykorzystywane do sortowania/grupowania po tych polach:

<field name="make_sort" type="lowercase" indexed="true" stored="false" />
<field name="model_sort" type="lowercase" indexed="true" stored="false" />

Pole zbiorcze, do którego będą kopiowane wartości z pól, po których chcemy wyszukiwać. Jako że do tego pola kopiujemy wartości z więcej niż jednego pola, musimy ustawić wartość atrybutu „multiValued” na true:

<field name="content" type="text" indexed="true" stored="false" multiValued="true"/>

Rok produkcji:

<field name="year" type="tint" indexed="true" stored="true" required="true" />

Cena:

<field name="price" type="tfloat" indexed="true" stored="true" />

Pojemność:

<field name="engine_size" type="tint" indexed="true" stored="true" />

Przebieg:

<field name="mileage" type="tint" indexed="true" stored="true" />

Kolor:

<field name="colour" type="lowercase" indexed="true" stored="true" />

Pamiętamy o wartości false dla atrybutu „indexed” dla pola „Czy uszkodzony”:

<field name="damaged" type="boolean" indexed="false" stored="true" />

Zostało nam przekopiować wartości z pól, po których wyszukujemy do jednego pola zbiorczego:

<copyField source="make" dest="content"/>
<copyField source="model" dest="content"/>
<copyField source="year" dest="content"/>

… i ponownie pola marki i modelu do pól, po których będziemy sortować:

<copyField source="make" dest="make_sort"/>
<copyField source="model" dest="model_sort"/>

Czy coś jeszcze do schemy?

Uzupełnijmy scheme jeszcze o 3 elementy:
Klucz unikalny dokumentu

<uniqueKey>id</uniqueKey>

Domyślne pole, po którym wyszukujemy

<defaultSearchField>content</defaultSearchField>

Domyślny operator, wykorzystywany przez parser zapytań do solr. Ustawmy go na wartość „AND”.

<solrQueryParser defaultOperator="AND"/>

Mamy zatem gotowy plik konfiguracyjny schema.xml! Zobaczmy jak wygląda w całej okazałości:

<?xml version="1.0" encoding="UTF-8" ?>
<schema name="carsale" version="1.2">
  <types>
   <fieldType name="string" sortMissingLast="true" omitNorms="true"/>
   <fieldType name="boolean" sortMissingLast="true" omitNorms="true"/>
   <fieldType name="tint" precisionStep="8" omitNorms="true" positionIncrementGap="0"/>
   <fieldType name="tfloat" precisionStep="8" omitNorms="true" positionIncrementGap="0"/>
   <fieldType name="text" positionIncrementGap="100">
     <analyzer>
       <tokenizer class="solr.WhitespaceTokenizerFactory"/>
       <filter class="solr.LowerCaseFilterFactory"/>
     </analyzer>
   </fieldType>
   <fieldType name="lowercase" positionIncrementGap="100">
     <analyzer>
       <tokenizer class="solr.KeywordTokenizerFactory"/>
       <filter class="solr.LowerCaseFilterFactory" />
       <filter class="solr.TrimFilterFactory" />
     </analyzer>
   </fieldType>
 </types>
 <fields>
   <field name="id" type="string" indexed="true" stored="true" required="true" />
   <field name="make" type="text" indexed="false" stored="true" required="true" />
   <field name="model" type="text" indexed="false" stored="true" required="true" />
   <field name="make_sort" type="lowercase" indexed="true" stored="false" />
   <field name="model_sort" type="lowercase" indexed="true" stored="false" />
   <field name="year" type="tint" indexed="true" stored="true" required="true" />
   <field name="price" type="tfloat" indexed="true" stored="true" />
   <field name="engine_size" type="tint" indexed="true" stored="true" />
   <field name="mileage" type="tint" indexed="true" stored="true" />
   <field name="colour" type="lowercase" indexed="true" stored="true" />
   <field name="damaged" type="boolean" indexed="false" stored="true" />
   <field name="content" type="text" indexed="true" stored="false" multiValued="true"/>
 </fields>
 <uniqueKey>id</uniqueKey>
 <defaultSearchField>content</defaultSearchField>
 <solrQueryParser defaultOperator="AND"/>
 <copyField source="make" dest="content"/>
 <copyField source="model" dest="content"/>
 <copyField source="make" dest="make_sort"/>
 <copyField source="model" dest="model_sort"/>
 <copyField source="year" dest="content"/>
</schema>

Podsumowując

W dzisiejszym wpisie udało nam się stworzyć plik schema.xml, który pomoże nam tak zaindeksować dane, abyśmy mogli zrealizować funkcjonalności wyszukiwania ogłoszeń naszego serwisu sprzedaży samochodów. Chcielibyśmy jednak rozwijać nasz serwis, co będzie się wiązało z dodatkowymi zmianami w pliku konfiguracyjnym … i nie tylko. W następnych artykułach z cyklu „sprzedaż samochodów” będziemy realizować nowe wymagania oraz wprowadzać kolejne modyfikacje.