Zaawansowane filtrowanie Symfony + Doctrine |
Zaawansowane filtrowanie Symfony + Doctrine |
19.04.2021, 18:55:31
Post
#1
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%) |
A napiszę coś może ciekawszego niż pytania o BOM, czy headers already sent
Opis tego co chciałbym uzyskać opiszę w skali micro. Musi to mieć przełożenie na skalę macro. Mamy sobie stronę z raportem. Raport dotyczy użytkowników (bazowa tabela) Muszę teraz dodać do tego filtrowanie - prościzna Jest sobie N filtrów po których mogę filtrować userów. Na cele demonstracyjne przyjmiemy: - filtrowanie po statusie użytkowania (tabela users) - filtrowanie po zamówieniach np. użytkownicy mający zamówienia w statusie pedding (tabela orders) - filtrowanie po produktach z zamówieć np: użytkownicy którzy zamówili zestaw X (tabela order_positions) - filtrowanie po adresach użytkowników (tabela user_adresses) Jak widać do każdego niemal filtra potrzebny jest LEFT JOIN z tabelką + odpowiedni WHERE Muszę zbudować w miarę przyjazne rozwiązanie które pozwoli mi zdefiniować Criteria filtrów które będą miały w sobie JOIN + CONDITIONS. Problemy które widzę to: - Kolejność JOIN ma znaczenie (chyba oczowiste) - Każde Criteria musi zawierać pełny zestaw danych typu JOIN i WHERE - Podczas aplikowania wielu Criterias JOIN muszą być odfiltrowane i wrzucone w odpowiedniej kolejności (jak określić wagę...) - i pewnie wiele innych Generalnie idealne rozwiązanie byłoby zrobić Kod new CriteriaCollection([ new OrderStatusCriteria(...), new OrderProductSthCriteria(...), ])->applyOn($qb) To taka rozkmina. Ma ktoś jakieś koncepcje albo rozwiązania? Zapraszam doo dyskusji PS. Inną metodą byłoby zbudowanie Grafu gdzie Vertex jest tabelą a Edge jest relacją między Vertexami. Przy robieniu A - C wybirać wszystko i skleić w kolejności w jakiej algo wyszuka ścieżkę (nie musi to być A - B - C ale może być A - D - E - C) |
|
|
20.04.2021, 15:56:29
Post
#2
|
|
Grupa: Zarejestrowani Postów: 1 270 Pomógł: 184 Dołączył: 7.10.2012 Skąd: Warszawa Ostrzeżenie: (0%) |
A może utworzyć odpowiednie traity z metodami ktore przyjmą query buildera i będą do niego doklejać odpowiednie filtry oczywiście taka metoda by zwracała voida jakby nie było np podanego filtra. Potem wystarczyło by w odpowiedniej kolejności uruchomić metody tych traitow.
Tak jeszcze mysle ze te metody w traitach mogły by sprawdzac czy istnieją jakieś joiny i jeśli istnieją to nie dodawać kolejnych Ten post edytował rad11 20.04.2021, 16:09:36 |
|
|
20.04.2021, 18:39:13
Post
#3
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%) |
@rad11
Chciałbym uniknąć Trait bo byłoby ich N w raporcie, a aktualnie i tak są tam metody które sprawdzają `if(filterBy_X) then $qb->where(...)` a joiny są wpakowane na sztywno. @kayman Tak, to już jest potworek Działa i ma się dobrze, ale sposób w jaki to zostało napisane powoduje spore problemy ze zrozumieniem, dodawaniem itd. @viking Nie dokładnie to samo ale Doctrine ma https://www.doctrine-project.org/projects/d...ce/filters.html Wpadł mi jeszcze do głowy pomysł ad moich Contexts. Mogę zbudować sobie ContextCollection ze wszystkimi dostępnymi Contextami. Potem odbierając request odpalę sobie CotextBuilder i wyciągnę wszystkie contexty które będą odpowiadały paramsom. W Context mogę sprawdzić czy QueryBuilder ma już wpisany alias do join i jeśli nie ma takowego to dodać, a jeśli już ma to nie a na końcu dodać tylko condition. Taki draft mojej myśli:
Ten post edytował Pyton_000 20.04.2021, 18:39:35 |
|
|
Wersja Lo-Fi | Aktualny czas: 13.06.2024 - 19:32 |