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ść
PS. Spodobał Ci się ten artykuł?