Niestety, nie ma usług idealnych. Do takich też nie należy, posiadający swoje ograniczenia, Azure Search. Jednym z nich jest zamknięty zbiór struktur danych, które możemy wykorzystać podczas tworzenia indexer-a (pełny zbiór możecie znaleźć w dokumentacji ). Co zrobić, gdy nasza struktura posiada zagnieżdżony obiekt? Poddać się? Pisać swoje rozwiązania technologiczne? Prawda jest przyjemniejsza. Nadal możemy, w dość prosty sposób. spłaszczyć zagnieżdżony obiekt przez mechanizm projekcji dostępny w bazie Azure CosmosDB.

Spłaszczanie – a co to?

Jeżeli pamiętacie mój ostatni artykuł na temat Azure Search, zapewne zauważyliście, że w wynikach zwracanych item-ów zabrakło pola autor. To właśnie pod tym polem krył się zagnieżdżony obiekt. Niestety, Azure Search nie daje nam obsługi własnych struktur out of the box. Kto wie, może w przyszłości taki piękny feature zostanie dodany.

Obecnie, aby dodać zagnieżdżony obiekt do indexer-a, musimy spłaszczyć strukturę. Oznacza to konieczność likwidacji zagłębienia, czyli należy przerobić taki obiekt:

{
   "title": "My Test Title",
   "description": "My Test Description",
   "author": {
      "fist": "FirstName",
      "last": "LastName"
   }
}

na taki:

{
   "title": "My Test Title",
   "description": "My Test Description",
   "author.fist": "FirstName",
   "author.last": "LastName"
}

Muszę wspomnieć, że z konwencją jest jak z kakałkiem. Jest wiele dobry, ale wybiera się jedno. Osobiście używam  {klucz}.{zagniezdzony klucz}. Taką przyjąłem i mi z tym dobrze. Nie jest to jednak najpopularniejsza wersja. W swojej karierze częściej spotykałem się z wersjami:

  • {klucz}${zagniezdzony klucz}
  • {klucz}.{zagniezdzony klucz}
  • {Klucz}{zagniezdzony Klucz}
  • {klucz}_{zagniezdzony klucz}

Oczywiście wybierając konwencje kierujcie się osobistymi preferencjami was jak i waszego zespołu. Chyba, że planujecie wykorzystywać o usługę Azure Search. Wtedy należy pamiętać, iż konfigurując ją z poziomu portalu zadziałają tylko dwie ostatnie konwencję, natomiast dwie pierwsze wymagają wykorzystania mechanizmu fields mapping.

Zapytanie kluczem do sukcesu

Jeżeli czytałeś mój ostatni artykuł o Azure Search to a. podziwiam, masz ogromną cierpliwość i/lub pociąg do wiedzy b. pewnie wiesz jak założyć bazę CosmosDB i dodać do niej usługę wyszukiwania. Jeżeli nie – zachęcam do lektury. Opis dalszych kroków rozpocznę od pierwszej różnicy: definicji źródła danych. Musimy zdefiniować zapytanie, po którym będą pobierane nowe rzeczy do zindeksowania.

Wykorzystując mechanizm projekcji danych, który mamy do dyspozycji w CosmosDB, wystarczy nam napisać zapytanie:

SELECT VALUE {
    "id": c.id,
    "title": c.title,
    "description": c.description,
    "author_first": c.author.first,
    "author_last": c.author.last,
    "tags": c.tags,
    "_ts": c._ts
}
FROM c WHERE c._ts >= @HighWaterMark ORDER BY c._ts

Pamiętajcie o dodaniu klucza _ts. To właśnie on służy do identyfikowania jeszcze nie zindeksowanych elementów. Co gorsze,  nie podanie go spowoduje, że Azure Portal przepuści was dalej i… wywali się dopiero przy zapisywaniu całej konfiguracji! <straszny, przeraźliwy dźwięk w tle> Tak, można wtedy powiedzieć kilka niemiłych słów 🙂

Przechodząc do tworzenia indeksu: w panelu otrzymamy brakujące wcześniej kolumny, na których możemy definiować wszystkie operacje.

Po skonfigurowaniu indeksu i zindeksowaniu danych możemy przejść do explorer-a. Przeszukując wszystkie elementy w naszej usłudze Azure Search zobaczymy, że w zwracanym JSON-ie pojawiły się brakujące kolumny pod postacią spłaszczonego obiektu.

Podsumowanie

W ten oto sposób otrzymaliśmy przeszukiwanie po zagnieżdżonym obiekcie. Dzięki zastosowaniu konwencji nazewnictwa możemy w prosty sposób parsować JSON-a na obiekt wykorzystując symbol _ jako znacznik zagłębienia.
W następnym artykule na temat Azure Search postaram się przedstawić wykorzystanie REST API do budowania wyszukiwarki bez źródła danych w chmurze Azure.

Mam nadzieje, że artykuł był przydatny i do następnego!

Cześć