MarkLogic cts: element-query false positive?

Question

Biorąc pod uwagę ten dokument: -

<items> 
    <item><type>T1</type><value>V1</value></item> 
    <item><type>T2</type><value>V2</value></item> 
</items> 

zaskoczeniem, uważam, że to będzie ciągnąć z powrotem na stronę w cts:uris(): -

cts:and-query((
    cts:element-query(xs:QName('item'), 
    cts:element-value-query(xs:QName('type'),'T1') 
    ), 
    cts:element-query(xs:QName('item'), 
    cts:element-value-query(xs:QName('value'),'V2') 
    ) 
)) 

ale nieco zaskakująco (dla mnie przynajmniej) Uważam też, że będzie to zbyt: -

cts:element-query(xs:QName('item'), 
    cts:and-query((
    cts:element-value-query(xs:QName('type'),'T1'), 
    cts:element-value-query(xs:QName('value'),'V2') 
    )) 
) 

nie wydaje się słuszne, ponieważ nie istnieje jeden element z type = T1 i wartość = V2. Dla mnie to wygląda na fałszywe pozytywne.

Czy źle zrozumiałem, jak działa cts:element-query? (Muszę powiedzieć, że dokumentacja nie jest szczególnie jasna w tej dziedzinie).

Czy jest to coś, w czym MarkLogic dąży do uzyskania oczekiwanego rezultatu, a gdybym miał więcej lub więcej indeksów na miejscu, byłbym mniej prawdopodobny, by uzyskać fałszywy pozytywny wynik.

Answer 1

Oprócz odpowiedzi @wst wystarczy włączyć element value positions, aby uzyskać dokładne wyniki z wyszukiwania niefiltrowanego. Oto niektóre kod, aby pokazać w ten sposób:

xdmp:document-insert("/items.xml", <items> 
    <item><type>T1</type><value>V1</value></item> 
    <item><type>T2</type><value>V2</value></item> 
</items>); 

cts:search(collection(), 
    cts:element-query(xs:QName('item'), 
    cts:and-query((
     cts:element-value-query(xs:QName('type'),'T1'), 
     cts:element-value-query(xs:QName('value'),'V2') 
    )) 
), 'unfiltered' 
) 

Bez element value positions włączona ta zwraca dokument testowy. Po włączeniu pozycji zapytanie nie zwraca nic.

Jak powiedział przez @wst, cts:search() biegnie filtrowane domyślnie, natomiast cts:uris() (i na przykład xdmp:estimate() tylko biegnie niefiltrowane.

HTH!

Answer 2

Tak, uważam, że jest to niewielkie nieporozumienie dotyczące działania zapytań. W wersji cts:search domyślnym działaniem jest włączenie opcji filtered. W tym przypadku ML oceni zapytanie przy użyciu tylko indeksów, a następnie po wybraniu dokumentów kandydujących załaduje je do pamięci, skontroluje i odfiltrowuje fałszywe alarmy. Jest to bardziej czasochłonne, ale dokładniejsze.

cts:uris to funkcja leksykonu, więc kwerendy przekazywane do niej będą rozwiązywać tylko za pośrednictwem indeksów i nie ma opcji filtrowania wyników fałszywie dodatnich.

Prostym sposobem na obsłużenie tego zapytania za pośrednictwem indeksów byłaby zmiana schematu, tak aby dokumenty były oparte na <item> zamiast na <items>. Następnie każdy element miałby osobny wpis indeksu, a wyniki nie byłyby zmieniane przed filtrowaniem.

Innym sposobem, który nie wymaga aktualizacji dokumentów, jest zawijanie zapytań, które mogą wystąpić w tym samym elemencie w cts:near-query. To uniemożliwiłoby <type> w jednym <item> dopasowanie z <value> w innym <item>. Sugeruję przeczytanie dokumentacji, ponieważ może być konieczne włączenie jednego lub więcej indeksów opartych na pozycjach dla cts:near-query, aby były dokładne.