solr.ReversedWildcardFilter

Filtr solr.ReversedWildcardFilter dostarcza nam do indeksu nowe tokeny, które są niejako odwróceniem tokenów w danym polu. Tokeny takie są wykorzystywane podczas wyszukiwania, w celu przyspieszenia zadawania zapytań, w których „dzikie karty” są na początku wyrażenia. Na poziomie konfiguracji filtr dostarcza nam następujące argumenty:

• withOriginal – jeżeli „true”, to generuj na tej samej pozycji zarówno tokeny oryginalne, jak i odwrócone. Jeżeli „false”, to generuj jedynie tokeny odwrócone.
• maxPosAsterisk – maksymalna pozycja „dzikiej karty” „*”, która uaktywnia korzystanie przez filtr z tokenów odwróconych. Jeżeli „*” pojawi się w zapytaniu na pozycji wyższej niż skonfigurowana, wtedy filtr nie będzie korzystał z tokenów odwróconych.
• maxPosQuestion – maksymalna pozycja „dzikiej karty” „?”, która uaktywnia korzystanie przez filtr z tokenów odwróconych.
• maxFractionAsterisk – dodatkowy parametr, który uaktywnia korzystanie z tokenów odwróconych, jeżeli pozycja „*” jest mniejsza niż skonfigurowana w tym parametrze wartość ułamkowa długości tokena zapytania.
• minTrailing – minimalna liczba znaków występujących po ostatniej „dzikiej karcie” w zapytaniu, która uaktywni nam korzystanie z tokenów odwróconych. W celach wydajnościowych zaleca się, aby wartość ta była większa niż 1.

Zmiany w schema.xml

Nowy filtr dodajemy do definicji typu „text” w następujący sposób:

<fieldType name="text" class="solr.TextField"
	positionIncrementGap="100">
	<analyzer type="index">
		<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" />
		<filter class="solr.ReversedWildcardFilterFactory" />
	</analyzer>
	<analyzer type="query">
		<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>

Filtr solr.ReversedWildcardFilter wykorzystujemy tylko na etapie indeksacji. Nie definiujemy żadnych argumentów w filtrze, ponieważ chcemy skorzystać ze standardowej konfiguracji, czyli wartości argumentów tego filtra domyślnie będą wyglądać tak:

• withOriginal – „true”, chcemy również mieć dostępne tokeny oryginalne, aby móc dalej korzystać z wyszukiwania bez „dzikich kart” po polach tego typu
• maxPosAsterisk – 2
• maxPosQuestion – 1
• maxPosQuestion – 0.0f (czyli funkcjonalność wyłączona)
• maxPosQuestion – 2

Przykładowe dane

Zaindeksujmy przykładowe dane do analizy:

<add>
  <doc>
    <field name="id">1</field>
    <field name="make">Lancia</field>
    <field name="model">Delta</field>
    ...
  </doc>
  <doc>
    <field name="id">2</field>
    <field name="make">Land Rover</field>
    <field name="model">Defender</field>
    ...
  </doc>
  <doc>
    <field name="id">3</field>
    <field name="make">Acura</field>
    <field name="model">MDX</field>
    ...
  </doc>
  <doc>
    <field name="id">4</field>
    <field name="make">Acura</field>
    <field name="model">RDX</field>
    ...
  </doc>
  <doc>
    <field name="id">5</field>
    <field name="make">Acura</field>
    <field name="model">RSX</field>
    ...
  </doc>
</add>

Tworzymy zapytania

Przypomnijmy, że domyślne wyszukiwanie odbywa się po polu „content”, w skład którego wchodzą między innymi pola „make” oraz „model”. W celach analizy wyników i działania filtra solr.ReversedWildcardFilter, ustawimy atrybut „stored” pola „content” na „true”. Dodamy również do zapytania argument debugQuery, który umożliwi nam obserwacje, z którego tokena (oryginalnego, czy odwróconego) korzysta filtr.

1. ?q=lan*&fl=id,content&debugQuery=on

   <result name="response" numFound="2" start="0">
     <doc>
       <arr name="content">
         <str>Lancia</str>
         <str>Delta</str>
         <str>2002</str>
       </arr>
       <str name="id">1</str>
     </doc>
     <doc>
       <arr name="content">
         <str>Land Rover</str>
         <str>Defender</str>
         <str>2002</str>
       </arr>
       <str name="id">2</str>
     </doc>
   </result>
   <lst name="debug">
     <str name="rawquerystring">lan*</str>
     <str name="querystring">lan*</str>
     <str name="parsedquery">content:lan*</str>
     <str name="parsedquery_toString">content:lan*</str>
     ...
   </lst>

   Użyliśmy „dzikiej karty” „*” na końcu zapytania (pozycja = 4), zatem filtr do wyszukiwania użył tokenów oryginalnych:

   <str name="parsedquery">content:lan*</str>

2. ?q=*dx&fl=id,content&debugQuery=on

   <result name="response" numFound="2" start="0">
     <doc>
       <arr name="content">
         <str>Acura</str>
         <str>MDX</str>
         <str>2002</str>
       </arr>
       <str name="id">3</str>
     </doc>
     <doc>
       <arr name="content">
         <str>Acura</str>
         <str>RDX</str>
         <str>2003</str>
       </arr>
       <str name="id">4</str>
     </doc>
   </result>
   <lst name="debug">
     <str name="rawquerystring">*dx</str>
     <str name="querystring">*dx</str>
     <str name="parsedquery">content:#1;xd*</str>
     <str name="parsedquery_toString">content:#1;xd*</str>
     ...
   </lst>

   Użyliśmy „dzikiej karty” „*” na początku zapytania (pozycja = 1) i dodatkowo mamy jeszcze dwa znaki po ostatniej „dzikiej karcie”. Filtr użył zatem tokenów odwróconych:

   <str name="parsedquery">content:#1;xd*</str>

   Jak widzimy, tokeny odwrócone są w indeksie poprzedzone specjalnym prefixem, aby nie doszło do wyszukania nieprawidłowych dokumentów.

3. ?q=r?x&fl=id,content&debugQuery=on

   <result name="response" numFound="2" start="0">
     <doc>
       <arr name="content">
         <str>Acura</str>
         <str>RDX</str>
         <str>2003</str>
       </arr>
       <str name="id">4</str>
     </doc>
     <doc>
       <arr name="content">
         <str>Acura</str>
         <str>RSX</str>
         <str>2006</str>
       </arr>
       <str name="id">5</str>
     </doc>
   </result>
   <lst name="debug">
     <str name="rawquerystring">r?x</str>
     <str name="querystring">r?x</str>
     <str name="parsedquery">content:r?x</str>
     <str name="parsedquery_toString">content:r?x</str>
     ...
   </lst>

   Użyliśmy „dzikiej karty” „?” na pozycji 2 oraz dodatkowo mamy tylko jeden znak występujący po ostatniej „dzikiej karcie”. Zatem filtr do wyszukiwania użył tokenów oryginalnych:

   <str name="parsedquery">content:r?x<</str>

Podsumowanie

Dzięki filtrowi solr.ReversedWildcardFilter zoptymalizowaliśmy zapytania z „dzikimi kartami”, zatem nasi użytkownicy mogą teraz efektywnie z takich zapytań korzystać

Specyfikacja wymagań

Chciałbym stworzyć zapytanie grupujące, które w odpowiedzi pokaże mi ilość wygenerowanych grup, oraz dostarczy po jednym dokumencie w każdej grupie – dokumencie określającym auto o najniższej cenie w swojej grupie rocznikowej.

Opis parametrów requestu nowej funkcjonalności

Potrzebujemy następujących parametrów:

• group.ngroups – parametr typu logicznego, który pozwoli nam na zawarcie w odpowiedzi ilości wygenerowanych grup
• group.sort – parametr opisujący sposób sortowania dokumentów wewnątrz grupy

Tworzymy zapytanie

Posługując się zapytaniem z poprzedniego postu, dodajemy dwa nowe parametry:

?q=audi+a4&group=true&group.field=year_group&group.limit=1&fl=id,mileage,make,model,year,price&group.ngroups=true&group.sort=price+asc

Zauważmy, że poza dodaniem parametrów group.ngroups oraz group.sort, ustawiliśmy także wartość parametru group.limit na 1 (tak abyśmy otrzymali tylko jeden dokument w każdej grupie) oraz dodaliśmy do parametru fl pole określające cenę auta. W rezultacie otrzymujemy:

<lst name="grouped">
  <lst name="year_group">
    <int name="matches">5</int>
    <int name="ngroups">3</int>
    <arr name="groups">
      <lst>
        <str name="groupValue">2002</str>
        <result name="doclist" numFound="2" start="0">
          <doc>
            <str name="id">3</str>
            <str name="make">Audi</str>
            <int name="mileage">125000</int>
            <str name="model">A4</str>
            <float name="price">21300.0</float>
            <int name="year">2002</int>
          </doc>
        </result>
      </lst>
      <lst>
        <str name="groupValue">2003</str>
        <result name="doclist" numFound="2" start="0">
          <doc>
            <str name="id">2</str>
            <str name="make">Audi</str>
            <int name="mileage">220000</int>
            <str name="model">A4</str>
            <float name="price">27800.0</float>
            <int name="year">2003</int>
          </doc>
        </result>
      </lst>
      <lst>
        <str name="groupValue">2006</str>
        <result name="doclist" numFound="1" start="0">
          <doc>
            <str name="id">5</str>
            <str name="make">Audi</str>
            <int name="mileage">9900</int>
            <str name="model">A4</str>
            <float name="price">32100.0</float>
            <int name="year">2006</int>
          </doc>
        </result>
      </lst>
    </arr>
  </lst>
</lst>

W odpowiedz pojawił nam się nowy element, określający ilość wygenerowanych grup:

<int name="ngroups">3</int>

W każdej grupie rocznikowej mamy po jednym dokumencie, jest to auto o najniższej cenie w swojej grupie. Nie wierzysz ? Przeanalizuj odpowiedzi zawarte w poprzednim poście i porównaj ceny

Podsumowanie

Był to szybki przegląd dwóch nowych parametrów powiązanych z funkcjonalnością grupowania wyników. Duże podziękowania dla Davida Martina za dostarczenie mi tematu poprzez dyskusję na temat poprzedniego postu

Opis parametrów requestu nowej funkcjonalności

Funkcjonalność grupowania wyników wyszukiwania jest dostępna od wersji solr 3.3. Przyjrzyjmy się podstawowym parametrom requestu, jakich będziemy potrzebowali:

• group – włącza/wyłącza grupowanie wyników
• group.field – nazwa pola, po którym chcemy pogrupować wyniki. Musimy zadbać o to aby pole, po którym chcemy grupować (rok produkcji), było w postaci tekstowej i nie było polem wielokrotnym
• group.query – zapytanie, które użyjemy w celu pogrupowania wyników po zakresie przebiegu auta
• group.limit – limit wyników wyszukiwania w każdej z grup

Te cztery podstawowe parametry pozwolą nam na zrealizowanie założeń.

Zmiany w schema.xml

Ewentualne zmiany w pliku schema.xml będą polegały na zadbaniu, aby pola, po których chcemy grupować wyniki wyszukiwania, było w postaci „string” lub „text”. Nasze wyniki chcielibyśmy grupować po polu „rok produkcji”. Dla przypomnienia, reprezentacja tego pola w tym momencie wygląda tak:

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

czyli jest to pole typu całkowitoliczbowego. W celu umożliwienia grupowania po tym polu tworzymy kolejne pole, które będzie odpowiednikiem pola „year”, ale w postaci tekstowej:

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

i kopiujemy zawartość pola „year” do pola „year_group”:

<copyField source="year" dest="year_group"/>

To praktycznie wszystkie zmiany jakie musimy dokonać w pliku konfiguracyjnym schema.xml.

Przykładowe dane

Stwórzmy teraz przykładowe dane w celu przetestowania nowej funkcjonalności. Załóżmy że mamy próbkę danych aut o marce Audi i modelu A4. Dwa z nich są z rocznika 2002, kolejne dwa z rocznika 2003 oraz jeden z rocznika 2006. Dodatkowo, jedno z aut ma przebieg poniżej 100 000 km, trzy mają przebieg od 100 000 do 199 999 km i jedno auto które ma przebieg co najmniej 200 000 km:

<add>
   <doc>
      <field name="id">1</field>
      <field name="make">Audi</field>
      <field name="model">A4</field>
      <field name="year">2002</field>
      <field name="price">22700</field>
      <field name="engine_size">1900</field>
      <field name="mileage">197000</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">A4</field>
      <field name="year">2003</field>
      <field name="price">27800</field>
      <field name="engine_size">1900</field>
      <field name="mileage">220000</field>
      <field name="colour">black</field>
      <field name="damaged">false</field>
      <field name="city">Bialystok</field>
      <field name="loc">53.08,23.09</field>
   </doc>
   <doc>
      <field name="id">3</field>
      <field name="make">Audi</field>
      <field name="model">A4</field>
      <field name="year">2002</field>
      <field name="price">21300</field>
      <field name="engine_size">1900</field>
      <field name="mileage">125000</field>
      <field name="colour">black</field>
      <field name="damaged">false</field>
      <field name="city">Szczecin</field>
      <field name="loc">53.25,14.35</field>
   </doc>
   <doc>
      <field name="id">4</field>
      <field name="make">Audi</field>
      <field name="model">A4</field>
      <field name="year">2003</field>
      <field name="price">30300</field>
      <field name="engine_size">1900</field>
      <field name="mileage">150000</field>
      <field name="colour">red</field>
      <field name="damaged">false</field>
      <field name="city">Gdansk</field>
      <field name="loc">54.21,18.40</field>
   </doc>
  <doc>
      <field name="id">5</field>
      <field name="make">Audi</field>
      <field name="model">A4</field>
      <field name="year">2006</field>
      <field name="price">32100</field>
      <field name="engine_size">1900</field>
      <field name="mileage">9900</field>
      <field name="colour">red</field>
      <field name="damaged">false</field>
      <field name="city">Swidnik</field>
      <field name="loc">52.15,21.00</field>
   </doc>
</add>

Tworzymy zapytania

Wykorzystując parametry opisane na początku artykułu, tworzymy zapytanie, które zwróci nam wyniki wyszukiwania dla zapytania „Audi A4” pogrupowane po roku produkcji auta:

?q=audi+a4&group=true&group.field=year_group&group.limit=2&fl=id,mileage,make,model,year

Jak widać, ograniczyliśmy nasze wyniki wyszukiwania do maksymalnie dwóch w każdej z grup. Wypiszemy sobie w response jedynie te pola, które dadzą nam czytelny obraz identyfikacji dokumentów, czyli identyfikator, przebieg, marka, model oraz rok produkcji. W rezultacie otrzymujemy w response:

<lst name="grouped">
  <lst name="year_group">
    <int name="matches">5</int>
    <arr name="groups">
      <lst>
        <str name="groupValue">2002</str>
        <result name="doclist" numFound="2" start="0">
          <doc>
            <str name="id">1</str>
            <str name="make">Audi</str>
            <int name="mileage">197000</int>
            <str name="model">A4</str>
            <int name="year">2002</int>
          </doc>
          <doc>
            <str name="id">3</str>
            <str name="make">Audi</str>
            <int name="mileage">125000</int>
            <str name="model">A4</str>
            <int name="year">2002</int>
          </doc>
        </result>
      </lst>
      <lst>
        <str name="groupValue">2003</str>
        <result name="doclist" numFound="2" start="0">
          <doc>
            <str name="id">2</str>
            <str name="make">Audi</str>
            <int name="mileage">220000</int>
            <str name="model">A4</str>
            <int name="year">2003</int>
          </doc>
          <doc>
            <str name="id">4</str>
            <str name="make">Audi</str>
            <int name="mileage">150000</int>
            <str name="model">A4</str>
            <int name="year">2003</int>
          </doc>
        </result>
      </lst>
      <lst>
        <str name="groupValue">2006</str>
        <result name="doclist" numFound="1" start="0">
          <doc>
            <str name="id">5</str>
            <str name="make">Audi</str>
            <int name="mileage">9900</int>
            <str name="model">A4</str>
            <int name="year">2006</int>
          </doc>
        </result>
      </lst>
    </arr>
  </lst>
</lst>

Przeanalizujmy sobie odpowiedź. Na dane zapytanie otrzymaliśmy 5 trafień:

<int name="matches">5</int>

Odpowiedź została podzielona na 3 niezależne grupy:

1. <str name="groupValue">2002</str>

   w której znalazły się dwa dokumenty (numFound=”2″), czyli auta z rocznika 2002

2. <str name="groupValue">2003</str>

   w której znalazły się dwa dokumenty (numFound=”2″), czyli auta z rocznika 2003

3. <str name="groupValue">2006</str>

   w której znalazł się jeden dokument (numFound=”1″), czyli auto z rocznika 2006

Zgadza się!

Skonstruujmy teraz zapytanie, które pogrupuje nam wyniki wyszukiwania po zakresie przebiegu samochodu. Zakładamy 3 zakresy:

1. <0km ; 99999km>
2. <100000km ; 199999km>
3. <200000km ; * >

Zapytanie:

?q=audi+a4&group=true&group.query=mileage:[0+TO+99999]&group.query=mileage:[100000+TO+199999]&group.query=mileage:[200000+TO+*]&group.limit=3&fl=id,mileage,make,model,year

Dostajemy odpowiedź:

<lst name="grouped">
  <lst name="mileage:[0 TO 99999]">
    <int name="matches">5</int>
    <result name="doclist" numFound="1" start="0">
      <doc>
        <str name="id">5</str>
        <str name="make">Audi</str>
        <int name="mileage">9900</int>
        <str name="model">A4</str>
        <int name="year">2006</int>
      </doc>
    </result>
  </lst>
  <lst name="mileage:[100000 TO 199999]">
    <int name="matches">5</int>
    <result name="doclist" numFound="3" start="0">
      <doc>
        <str name="id">1</str>
        <str name="make">Audi</str>
        <int name="mileage">197000</int>
        <str name="model">A4</str>
        <int name="year">2002</int>
      </doc>
      <doc>
        <str name="id">3</str>
        <str name="make">Audi</str>
        <int name="mileage">125000</int>
        <str name="model">A4</str>
        <int name="year">2002</int>
      </doc>
      <doc>
        <str name="id">4</str>
        <str name="make">Audi</str>
        <int name="mileage">150000</int>
        <str name="model">A4</str>
        <int name="year">2003</int>
      </doc>
    </result>
  </lst>
  <lst name="mileage:[200000 TO *]">
    <int name="matches">5</int>
    <result name="doclist" numFound="1" start="0">
      <doc>
        <str name="id">2</str>
        <str name="make">Audi</str>
        <int name="mileage">220000</int>
        <str name="model">A4</str>
        <int name="year">2003</int>
      </doc>
    </result>
  </lst>
</lst>

Ponownie otrzymaliśmy 5 wyników. W pierwszej grupie znalazło się auto o przebiegu 9900 km, w drugiej grupie auta o przebiegach 197000 km, 125000 km oraz 150000 km, a w trzeciej auto o największym przebiegu, czyli 220000 km.
Otrzymaliśmy to co chcieliśmy osiągnąć. Zadanie wykonane.

Podsumowanie

Kolejna funkcjonalność, tym razem związana z grupowaniem wyników wyszukiwania, została dodana do naszej aplikacji sprzedaży samochodów. Zobaczymy jak zareagują na nią klienci

Analiza wymagań

Nasza baza samochodów jest już tak duża, że zawiera nazwy marek i modeli, których poprawne napisanie może sprawiać naszym klientom problemy, np:

1. • marka: Bugatti
   • model: Veyron
2. • marka: Daewoo
   • model: Lacetti
3. • marka: Cadillac
   • model: Brougham
4. • marka: Ford
   • model: Capri
5. • marka: Maserati
   • model: Coupe

Przykłady zapytań, które zwróciły 0 wyników, ze względu na niepoprawnie wpisane nazwy (frazy):

1. ?q=bugati+weyron
2. ?q=daewo+laceti
3. ?q=cadilac+brogham
4. ?q=ford+kapri
5. ?q=maseratti+coupe

Chcemy dodać funkcjonalność, która przy niepoprawnie wpisanych nazwach podpowie nam frazę, którą najprawdopodobniej klient miał na myśli, a której zastosowanie pozwoli nam wyszukać dokumenty związane z tą frazą.

Zmiany w solrconfig.xml

Najważniejszym elementem, który musimy dodać do pliku konfiguracyjnego solrconfig.xml jest komponent wykorzystujący klasę solr.SpellCheckComponent. Spróbujemy wykorzystać najprostszą, standardową konfigurację tego komponentu i przekonamy się, jak jego działanie sprawdzi się w praktyce:

<searchComponent name="spellcheck" class="solr.SpellCheckComponent">
    <lst name="spellchecker">
      <str name="classname">solr.IndexBasedSpellChecker</str>
      <str name="spellcheckIndexDir">./spellchecker</str>
      <str name="field">content</str>
      <str name="buildOnCommit">true</str>
    </lst>
</searchComponent>

Wyjaśnijmy sobie co znaczą poszczególne atrybuty:

1. • classname – klasa która jest implementacją naszego mechanizmu podpowiadania poprawnej frazy wyszukiwania. Wykorzystujemy klasę solr.IndexBasedSpellChecker, która jako źródło podpowiedzi wykorzystuje indeks solr.

   • spellcheckIndexDir – katalog, w którym przechowywany będzie indeks mechanizmu popowiedzi.

   • field – nazwa pola zdefiniowanego w pliku schema.xml, wykorzystywanego jako pole źródłowe do generowania indeksu dla mechanizmu podpowiedzi. W naszym przypadku będzie to pole o nazwie „content”, co zostanie uzasadnionej później.

   • buildOnCommit – jeżeli atrybut ten będzie ustawiony na wartośc true, to indeks mechanizmu podpowiedzi zostanie automatycznie wygenerowany przy każdym uaktualnieniu (commit) indeksu solr.

Mamy już zdefiniowany komponent, zatem teraz należy go wykorzystać w którymś z handler’ów, aby można było się do niego odwoływać. Najlepiej dodać go do handler’a, którego domyślnie używamy do wyszukiwania dokumentów. W ten sposób będziemy mogli za pomocą tylko jednego żądania otrzymywać wyniki wyszukiwania wraz z podpowiedzią. Przed uaktualnieniem, nasz domyślny handler wyglądał tak:

<requestHandler name="standard" class="solr.SearchHandler" default="true">
     <lst name="defaults">
       <str name="echoParams">explicit</str>
     </lst>
</requestHandler>

Po zmianie, wygląda tak:

<requestHandler name="standard" class="solr.SearchHandler" default="true">
     <lst name="defaults">
       <str name="echoParams">explicit</str>
       <str name="spellcheck">true</str>
       <str name="spellcheck.collate">true</str>
     </lst>
     <arr name="last-components">
       <str>spellcheck</str>
     </arr>
</requestHandler>

Jak widać, oprócz naszego komponentu spellcheck, dodaliśmy również dwie domyślne wartość wykorzystywane w zapytaniach:

1. • spellcheck – ustawienie wartości na true powoduje że dla każdego requestu nastąpi próba wygenerowania podpowiedzi.

   • spellcheck.collate – ustawienie wartości na true powoduje że mechanizm wybiera najlepszą podpowiedź dla każdego wyrazu i konstruuje nowe zapytanie składające się z tych podpowiedzi. Jeżeli mechanizm uzna, że dany wyraz jest poprawny, zostawia go w niezmienionej postaci.

Zmiany w schema.xml

Ewentualne zmiany w pliku schema.xml będą polegały na dodaniu pola, wykorzystywanego przez komponent solr.SpellCheckComponent jako źródło danych do generowania indeksu dla mechanizmu podpowiedzi. Pole takie powinno zawierać wszystkie informacje, jakie chcielibyśmy aby było użyte przy tworzeniu indeksu dla mechanizmu podpowiedzi. Typ takiego pola powinien zapewniać odpowiednią tokenizację indeksowanych danych, jak i być pozbawionym wszelkich filtrów używających stemmingu czy lametyzacji, co by mogło niekorzystnie wpłynąć na wyniki podpowiedzi.

Nasza schema posiada już pole spełniające wszystkie te wymaganie, a nazywa się „content”. Dla przypomnienia, jest to pole domyślne, po którym realizowane jest wyszukiwanie przez silnik solr. Przypomnijmy sobie aktualną definicję tego pola, jak i jego typu:

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

<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>

Do pola „content” kopiowane są wartości z pól marki, modelu i roku:

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

Tworzymy zapytania

Wykorzystamy zapytania z analizy wymagań, które nie zwróciły nam żadnych wyników, dodając parametr spellcheck.q, gdzie wpisujemy tę samą frazę co dla parametru q. W ten sposób, za pomocą jednego zapytania zwrócimy wyniki wyszukiwania wraz z wynikami mechanizmu podpowiedzi:

1. ?q=bugati+weyron&spellcheck.q=bugati+weyron

   <result name="response" numFound="0" start="0" />
   <lst name="spellcheck">
     <lst name="suggestions">
       <lst name="bugati">
         <int name="numFound">1</int>
         <int name="startOffset">0</int>
         <int name="endOffset">6</int>
         <arr name="suggestion">
           <str>bugatti</str>
         </arr>
       </lst>
       <lst name="weyron">
         <int name="numFound">1</int>
         <int name="startOffset">7</int>
         <int name="endOffset">13</int>
         <arr name="suggestion">
           <str>veyron</str>
         </arr>
       </lst>
         <str name="collation">bugatti veyron</str>
       </lst>
   </lst>

   Mechanizm podpowiedzi poprawił nam wyrazy zapytania na poprawne i dodatkowo funkcjonalność „collation” wygenerowała nam gotowe zapytanie, które możemy wykorzystać w celach zwrócenia nam poprawnych wyników wyszukiwania. Sprawdźmy kolejne przykłady:

2. ?q=daewo+laceti&spellcheck.q=?q=daewo+laceti

   <result name="response" numFound="0" start="0" />
   <lst name="spellcheck">
     <lst name="suggestions">
       <lst name="daewo">
         <int name="numFound">1</int>
         <int name="startOffset">0</int>
         <int name="endOffset">5</int>
         <arr name="suggestion">
           <str>daewoo</str>
         </arr>
       </lst>
       <lst name="laceti">
         <int name="numFound">1</int>
         <int name="startOffset">6</int>
         <int name="endOffset">12</int>
         <arr name="suggestion">
           <str>lacetti</str>
         </arr>
       </lst>
         <str name="collation">daewoo lacetti</str>
       </lst>
   </lst>

3. ?q=cadilac+brogham&spellcheck.q=cadilac+brogham

   <result name="response" numFound="0" start="0" />
   <lst name="spellcheck">
     <lst name="suggestions">
       <lst name="cadilac">
         <int name="numFound">1</int>
         <int name="startOffset">0</int>
         <int name="endOffset">7</int>
         <arr name="suggestion">
           <str>cadillac</str>
         </arr>
       </lst>
       <lst name="brogham">
         <int name="numFound">1</int>
         <int name="startOffset">8</int>
         <int name="endOffset">15</int>
         <arr name="suggestion">
           <str>brougham</str>
         </arr>
       </lst>
         <str name="collation">cadillac brougham</str>
       </lst>
   </lst>

4. ?q=ford+kapri& spellcheck.q=?q=ford+kapri

   <result name="response" numFound="0" start="0" />
   <lst name="spellcheck">
     <lst name="suggestions">
       <lst name="kapri">
         <int name="numFound">1</int>
         <int name="startOffset">5</int>
         <int name="endOffset">10</int>
         <arr name="suggestion">
           <str>capri</str>
         </arr>
       </lst>
         <str name="collation">ford capri</str>
       </lst>
   </lst>

5. ?q=maseratti+coupe&spellcheck.q=?q=maseratti+coupe

   <result name="response" numFound="0" start="0" />
   <lst name="spellcheck">
     <lst name="suggestions">
       <lst name="maseratti">
         <int name="numFound">1</int>
         <int name="startOffset">0</int>
         <int name="endOffset">9</int>
         <arr name="suggestion">
           <str>maserati</str>
         </arr>
       </lst>
         <str name="collation">maserati coupe</str>
       </lst>
   </lst>

Mechanizm spellcheck zadziałał dla naszych przypadków perfekcyjnie, poprawiając błędnie wpisane wyrazy i generując poprawne zapytanie. W dwóch ostatnich przypadkach (4,5) możemy zaobserwować że mechanizm nie wygenerował podpowiedzi dla poprawnie wpisanych wyrazów (4 – ford, 5 – coupe) lecz wykorzystał je do złożenia poprawnego zapytania (collation).

Podsumowanie

Nasz silnik wyszukiwania został wzbogacony o funkcjonalność sprawdzania poprawności wpisanej frazy. Zostało nam czekać na opinie klientów … i być może jakieś uwagi.

<field name="city_sort" type="lowercase" indexed="true" stored="false" />
...
<copyField source="city" dest="city_sort"/>

Okazało się jednak, że sortowanie po miejscowości (pole city_sort) nie funkcjonuje tak jak powinno, a wszystko ze względu na występowanie w nazwach miast polskich znaków. Co z tym zrobić ?

Analiza wymagań

Sprawdźmy, czy faktycznie sortowanie po polu „city_sort” nie uwzględnia polskich znaków. Zadajmy zapytanie:

q=*:*&fl=city&sort=city_sort+asc

Otrzymujemy rezultat:

<result name="response" numFound="6" start="0">
   <doc>
      <str name="city">Białystok</str>
   </doc>
   <doc>
      <str name="city">Koszalin</str>
   </doc>
   <doc>
      <str name="city">Szczecin</str>
   </doc>
   <doc>
      <str name="city">Warszawa</str>
   </doc>
   <doc>
      <str name="city">Świdnik</str>
   </doc>
   <doc>
      <str name="city">Łowicz</str>
   </doc>
</result>

Rzeczywiście, wyniki nie są posortowane poprawnie. Oczekiwaliśmy takiego rezultatu:

<result name="response" numFound="6" start="0">
   <doc>
      <str name="city">Białystok</str>
   </doc>
   <doc>
      <str name="city">Koszalin</str>
   </doc>
   <doc>
      <str name="city">Łowicz</str>
   </doc>
   <doc>
      <str name="city">Szczecin</str>
   </doc>
   <doc>
      <str name="city">Świdnik</str>
   </doc>
   <doc>
      <str name="city">Warszawa</str>
   </doc>
</result>

W celu usprawnienia sortowania danych zawierających polskie znaki wykorzystamy filtr „solr.CollationKeyFilter”.

solr.CollationKeyFilter

Filtr solr.CollationKeyFilter jest wykorzystywany podczas indeksowania, dodając do indeksu specjalne „klucze sortujące”. Pozwala nam na wskazanie kolatora powiązanego z konkretnym krajem i językiem. Możemy również określić „siłę” kolatora, która definiuje pewien minimalny poziom różnic jaki jest brany pod uwagę przy porównywaniu. Przykład:

<filter class="solr.CollationKeyFilterFactory" language="es" country=”ES” strength="primary" />

Powyższy przykład jest definicją fabryki dla filtra solr.CollationKeyFilter, określającego kolator dla języka hiszpańskiego z siłą primary.

Zmiany w schema.xml

1. Definicja nowych typów pól:

   <fieldType name="polishLowercase" positionIncrementGap="100">
     <analyzer>
       <tokenizer class="solr.KeywordTokenizerFactory"/>
       <filter class="solr.LowerCaseFilterFactory" />
       <filter class="solr.TrimFilterFactory" />
       <filter class="solr.CollationKeyFilterFactory"  language="pl" country=”PL” strength="primary" />
     </analyzer>
   </fieldType>

   Jak widać jest to tak naprawdę definicja już istniejącego typu „lowercase” uzupełnionego o filtr solr.CollationKeyFilter, określającego kolator dla języka polskiego. Będziemy używać tego typu pola do definiowania pól, które zawierają dane z polskimi znakami.

2. Zmiana definicji pola „city_sort”:
   • zmieniamy typ dla pola „city_sort” na nowo zdefiniowany typ „polishLowercase”:

   <field name="city_sort" type="polishLowercase" indexed="true" stored="false" />

Testy funkcjonalności

Zanim przetestujemy, czy zmiana typu pola przyniosła oczekiwany rezultat, pamiętajmy, że filtr solr.CollationKeyFilter wykorzystywany w tym typie działa na etapie indeksacji. Należy zatem wykonać pełną reindeksację danych.

Sprawdźmy teraz wynik zapytania, które wykorzystaliśmy wcześniej do przetestowania jakości sortowania:

q=*:*&fl=city&sort=city_sort+asc

Jak się okazuje, otrzymujemy oczekiwany wcześniej, poprawny rezultat:

<result name="response" numFound="6" start="0">
   <doc>
      <str name="city">Białystok</str>
   </doc>
   <doc>
      <str name="city">Koszalin</str>
   </doc>
   <doc>
      <str name="city">Łowicz</str>
   </doc>
   <doc>
      <str name="city">Szczecin</str>
   </doc>
   <doc>
      <str name="city">Świdnik</str>
   </doc>
   <doc>
      <str name="city">Warszawa</str>
   </doc>
</result>

Podsumowanie

Kolejny zgłoszony problem został pomyślnie rozwiązany. Usprawniliśmy jakość wyników sortowania po polskich znakach, wykorzystując nieskomplikowany, ale jakże pomocny filtr solr.CollationKeyFilter. Czekamy na dalsze zgłoszenia

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ń

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.