Puncte:1

Este posibil să utilizați o subinterogare într-o interogare de entitate?

drapel ai

Cum pot adăuga o condiție la o interogare de entitate Drupal 9 folosind o altă interogare de entitate pe un alt tip de entitate?

Voi ilustra întrebarea prin descrierea unui anumit caz de utilizare, deși nu cred că ar fi dificil să vin cu un număr de cazuri de utilizare plauzibile.

Aplicația pentru acest caz de utilizare urmărește articolele din literatura medicală publicată. Un articol este reprezentat de un tip de entitate personalizată care urmărește când a fost importat în sistem, dacă a fost obținut textul integral al articolului, ce subiecte au fost atribuite articolului pentru care cicluri de revizuire, când și în ce jurnal a fost publicate și multe alte informații.

Există un al doilea tip de entitate personalizată pentru a reprezenta loturi („pachete”) de articole atribuite pentru revizuire, urmărirea când au fost atribuite loturile, pentru ce subiecte și cărora specialiști în oncologie, precum și care au fost rezultatele acelor recenzii. Un articol poate fi atribuit mai multor pachete de recenzii, fiecare cu mai mulți recenzenți alocați și fiecare pachet de recenzii poate solicita recenzii pentru orice număr de articole.

Modulul de căutare pentru această aplicație are o cerință ca articolele să poată fi căutate pe baza multor criterii diferite, dintre care majoritatea pot fi aplicate prin inspectarea Articol entități, dar unele dintre ele pot fi implementate doar analizând valorile din Pachet entitati. Un exemplu de căutare ar putea, de exemplu, să solicite găsirea tuturor articolelor publicate în ultimele douăsprezece luni în revista J și desemnate pentru revizuire de către recenzentul R.

Într-un CMS mai potrivit pentru a lucra direct cu tabelele SQL relaționale, ar fi foarte simplu să sprijiniți o astfel de căutare folosind câteva îmbinări de tabele. Dar Drupal face această abordare mai puțin atrăgătoare, deoarece nu avem nicio garanție documentată că convențiile de denumire a tabelelor și coloanelor de sub entități pot fi bazate pe că nu se vor schimba.

Aș putea crea și executa două interogări de entitate separate și să folosesc rezultatele celei de-a doua pentru a elimina rezultatele returnate de prima interogare care nu sunt prezente și în rezultatele celei de-a doua. Dar printre dezavantajele acestei abordări se numără și faptul că rupe mecanismul de paginare Drupal.

Aș putea încerca să imit ceea ce ar face DBMS-ul mult mai eficient, introducând ID-urile entității returnate de a doua interogare într-o condiție la prima interogare, dar cine știe ce limite interne ar putea întâlni atunci când rezultatele celei de-a doua interogări sunt imens?

Aș putea implementa un kludge pentru a denormaliza datele, stocând referințe de entități din Articol entități înapoi la Pachet entități care, la rândul lor, indică înapoi către Articol entități, dar știm cu toții problemele legate de încercarea de a menține sincronizate aceleași informații în mai multe locuri.

Dacă toate căutările au fost pentru articole alocate pentru revizuire, puteam să întorc lucrurile și să folosesc o interogare de entitate pe Pachet tip, în urma trimiterii sale la Articol entități pentru celelalte criterii care trebuie testate. Dar un procent mare din căutări sunt menite să găsească articole, indiferent dacă acestea au fost sau nu alocate pentru revizuire. Deci, pentru această cale, ar trebui să implementez două seturi separate de logică de căutare în paralel, unul pentru căutări care implică atribuirea pachetelor de revizuire și al doilea pentru căutări cărora nu le pasă de atribuirea pentru revizuire. Și această abordare încă nu s-ar adresa căutărilor care caută în mod explicit articole care au nu fost repartizat spre revizuire. Și rețineți că păstrez acest exemplu de caz de utilizare simplu, limitându-l la doar două tipuri de entități.

Căutarea pe Google (și căutarea pe acest forum) mă redirecționează în permanență către informații despre utilizarea API-urilor de interogare a bazei de date de bază în loc de sistemul de interogare a entităților, cel puțin cu termenii de interogare pe care îi folosesc.

Există o modalitate de a utiliza o subinterogare (sau chiar mai bine, de a se alătura unui alt tip de entitate) în API-urile de interogare de entitate? Dacă nu, există perspective de sprijinire a unei astfel de funcționalități în discuție în Drupal Valhalla?

drapel cn
Pentru căutări complicate care implică mai multe tipuri de entități, [Search API](https://www.drupal.org/project/search_api) și [Search API Solr](https://www.drupal.org/project/search_api_solr) sunt soluție excelentă care vă oferă control deplin pentru a construi indexul așa cum doriți. Desigur, marele dezavantaj al acestui lucru este că trebuie să configurați și Solr.
drapel ai
Mulțumesc, @Patrick. Voi arunca o privire.
drapel in
API-ul de căutare este o sugestie bună. Procedând astfel, veți lucra cu o vizualizare, mai degrabă decât cu o interogare de entitate. În plus, vă puteți spori proiectul utilizând pachete de entități și câmpuri de referință pentru entități.Nu v-am văzut menționând dacă ați făcut acest lucru, dar ar putea fi util să începeți prin a defini toate entitățile dvs. ca pachete de un singur tip de entitate. Vederea dvs. va putea apoi să detalieze toate tipurile de pachete simultan. Câmpurile Entity Reference vor permite crearea de relații explicite între entități; utilizați cardinalitatea câmpului pentru a stabili o relație unu-la-unu sau unu-la-mulți.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.