2016-02-11 16 views
6

Mam kwerendy MySQL:Replikacja LEFT JOIN na wielu polach w Solr

select t1.to_step,count(t1.to_step) from tmp t1 left join tmp t3 on 
(t1.to_step = t3.from_step and t1.applicant_id=t3.applicant_id) 
where t3.to_step is null group by t1.to_step 

Próbuję zrobić powyższe solr za pomocą łączy. Wiem, że sprzężenia w solr działają jak zapytanie zagnieżdżone, ale nie jestem w stanie znaleźć właściwego sposobu na uzyskanie wszystkich rekordów, jak otrzymuję z zapytania mysql.

poniżej to czego używam:

q: "-_query_:\"{!join from=from_step_s to=to_step_s}from_step_s:[* TO *]\"", 

To daje mi częściowy zestaw wyników. Zasadniczo mój dokument solr składa się z pól applicant_id, from_step_s i to_step_s i chcę uzyskać dokument, w którym nie ma połączenia od to_step_s do from_step_s dla konkretnego zestawu applicant_id. Myślę, że problem jest gdzieś ze względu na applicant_id łączenie nie wykonywane w zapytaniu Solr (co nie wiem jak to zrobić), z powodu którego from_step_s jednego dokumentu zostanie dopasowany do to_step_s innego dokumentu z innym applicant_id.

Odpowiedz

2

Twoje pytanie dotyczy połączenia w oparciu o dwa pola (z każdej strony).

Krótka odpowiedź: Nie możesz tego zrobić.

Główna logika dla JoinQuery znajduje się w org.apache.solr.search.JoinQuery.JoinQueryWeight.getDocSet(). Jak widać nie ma tu zastosowania przechowywanych pól ani wyszukiwania, które można zmienić z jednego pola na dwa.

Erick Erickson odpowiedź:

Nie należy tego robić.

Solr żyje od dendryzacji. Dlaczego nie dodać nowego pola i połączyć stare? Dlaczego nie użyć sprzężenia sql w czasie indeksowania i dodać potrzebne informacje bezpośrednio do indeksu?

+0

Ale czy jest sposób, w jaki mogę powtórzyć zestaw wyników zapytania nadrzędnego z wewnątrz podkwerendy lub coś podobnego do iteracji w zestawie wynikowym? –

+0

Próbuję zaimplementować statystykę .. to dlatego wymóg.if wstępnie obliczam i przechowuję statystyki wymagałoby bardzo częstych aktualizacji .. –

+1

Jeśli czas nie ma znaczenia: Możesz zbudować własny QueryComponent lub QParser i pracować bezpośrednio na lucene indeks. Jeśli wszystkie twoje "claim_id" z wszystkimi odpowiednimi DocSets mogą być buforowane w pamięci głównej, możesz nawet pomyśleć o własnej wersji JoinQuery. –