[Spake]

Mirki, mam #pytanie do #symfony2 #php #angularjs - po raz drugi, bardziej sprecyzowane (⌐ ͡■ ͜ʖ ͡■)

- Mam sobie listę złożonych wniosków w panelu admina w różnych kategoriach
- Obok każdej kategorii chcę umieścić liczbę NOWYCH, nie rozpatrzonych przez admina wniosków

Wszystko to jest oparte na AngularJS, więc w Symfony jest to REST API.

I teraz nie wiem jak tą liczbę nowych wniosków wykonać.
Czy:
- wysyłać nowy request do API z liczbą nowych wniosków w danej kategorii (trochę głupie, nawet bardzo)
- wysyłać to do Angulara razem z obiektem kategorii, czyli np.
category_name: Sport
nierozpatrzone: 14

Ten drugi sposób uważam za bardziej poprawny, więc:
- jak wykonać to od strony Symfony, tj. w encji z kategorią wniosków dodać pole unread (które będzie bez adnotacji @ORM, czyli bez odzwierciedlenia w bazie) i później po pobraniu kategorii przepuścić je przez foreach i dopisać do tego pola "unread" liczbę nierozpatrzonych wniosków ? (⌐ ͡■ ͜ʖ ͡■) Januszowe bardzo, tak więc nie wiem w jaki sposób to rozwiązać :(

[MacDada]

@Spake:

1. Rozumiem, że „wniosek” to jest Doctrine'owa encja (i tabelka w bazie)?
2. Rozumiem, że „kategoria” to jest Doctrine'owa encja (i tabelka w bazie)?
3. Rozumiem, że masz relację kategoria może posiadać wiele wniosków (one to many)?
4. Co to znaczy, że „wniosek” jest „rozpatrzony”?

[Spake]

@MacDada: wniosek jest rozpatrzony wtedy, kiedy w tabeli jest rejected = 1 bądź accepted = 1.
relacja -> we wnioskach jest id kategorii, do ktorej przynalezy.
1. i 2. - tak

[MacDada]

@Spake: No to masz dwie opcje:

a.) kiedy pobierasz kategorię, zaciągać razem z nią wnioski i w pętli zliczyć ile pozostało nowych
b.) „keszować” sobie tę informację w kategorii – czyli do kategorii dołożyć dodatkową kolumnę i za każdym razem, gdy ustalasz jakiś wniosek, zwiększać/zmniejszać licznik dla kategorii

[MacDada]

@Spake: Opcja b ma tę wadę, że musisz w kodzie pilnować czy aby zawsze kolumna w z „kategorii” jest aktualizowana przy zmianach we „wnioskach”. Może się to rozjechać.

Ale za to, gdybyś tych wniosków miał dużo, można oszczędzić trochę procka/pamięci.

[Jurigag]

@Spake: ke ? a to nie jest po prostu sqlowy count ? lul ?

[Spake]

@MacDada: a) to już chyba lepiej zapytaniem będzie lepiej to zliczyć - mniej procka i pamięci to zeżre. Ogólnie wiem jak to zrobić, policzyć - ale jak je przekazać - o to się rozchodzi. Dodać dodatkowe pole w encji które nie będzie wprowadzone do bazy i przy pobieraniu kategorii wlepiać tam pętlą właśnie ilość?

[Spake]

@Jurigag: Rozchodzi się o sposób przekazania tego. Myślę, że da się to zrobić lepiej niż za każdym razem pobierać w kontrolerze kategorie, przepętlowywać je i dodawać do pola $iloscNowychWnioskow liczbę nowych wnioskow?;p

[Jurigag]

@Spake: ke ? przecież w sqlu w doctrine możesz zrobić COUNT(kolumna) i dziękuję ? XD i w wyniku doctrinea to mieć ? doctrine to tylko coś nad pdo, nadal oferuje to 90% możliwości sqla(bo czasem nie ma funkcji, ale to mozna sobie napisać/znaleźć na necie)

[Spake]

@Jurigag: dobra, ale jak to dodasz do obiektu który zwraca API ? xD Nie rozumiemy sie do konca

[Jurigag]

@Spake: normalnie ? api/doctrine zwróci count i tablicę obiektów ? lol

[Spake]

@Jurigag: ok, to mi pokaż przykładowe zapytanie zrobione w ten sposób ( ͡° ͜ʖ ͡°)

[Spake]

@Jurigag: oczywiście zrobione w DQL czy tam querybuilderze

[MacDada]

a) to już chyba lepiej zapytaniem będzie lepiej to zliczyć - mniej procka i pamięci to zeżre

@Spake: Yep, jest to też sposób na optymalizację. Ale ja wychodzę z założenia, że wolę mieć jak najwięcej czystego kodu (niezależnego od infrastruktury), ale takiego, który mogę łatwo przetestować. W końcu implementacja jest prosta to i napisanie testu jest proste.

Optymalizuję dopiero jak zaczynają się problemy z wydajnością lub jestem pewien, że takie problemy

[Jurigag]

@Spake:

$query = $em->createQueryBuilder()
 ->select('a,(SELECT COUNT(b.id) FROM XYZ:Def b WHERE asd = 1) as count')
 ->from('Xyz:Abc','a')
 ->select('c,m,r,e,p')->getQuery()->getResult();

[Spake]

@MacDada: nope. Mój kod wygląda tak:
$events = $em->getRepository('AppBundle:Event')->findAll();
$view = $this->view($events, 200);

return $this->handleView($view);

events - te "kategorie", applications - "wnioski". Zwracam wszystkie events(kategorie) naraz, a nie po kolei. Dlatego to jest trochę trudniejsze i pole w encji wydawało mi się wcześniej lepsze. W takim wypadku jak to lepiej rozwiązać?

[MacDada]

@Jurigag: Zapewne się zgadza (nie chce mi się analizować), ale jak teraz napiszesz test do tego? Podobnie jak do implementacji w PHP. Tyle, że będziesz musiał się łączyć z bazką, odpalać Doctrine, ogólnie test będzie powolny.

Jednocześnie, jeśli tych rekordów w kategorii nie jest specjalnie dużo i jeśli strona nie jest mega intensywnie używana (a nie jest, bo to adminownia), to prefereuję tak:

class UnreadProposalsInCategoryCounter
{
    public function countForCategory(Category $category)
    {

[Jurigag]

@Spake: query builderem dałem ci wyżej, dodaj sobie metodę do repo i tyle

[MacDada]

$view = $this->view($events, 200);

$this->handleView($view);

@Spake: Nie wiem co to robi :P

[Jurigag]

@MacDada: latanie po całej tablicy szybkie? XD