@Bruno_: a w transakcji to robisz?

@Bruno_: kurła usunąłem niechcący. Ogólnie wyżej pytałem co dokładnie chcesz osiągnąć tym zapytaniem?

@Bruno_: Musisz to poprostu wykonać w transakcji. Oznacz swoje repo albo metode anntoacją @Transactional i będzie gites

@Bruno_: zajrzałem jeszcze w twoje repo i widzę, że posty w użytkowniku trzymasz w liście. Zastanów się czy rzeczywiście potrzebujesz listy i doczytaj o konsekwencjach używania list w encjach w JPA(a dokladniej Hibernate)

@Bruno_ Uczysz się więc chcę cię tylko nakierować. Można użyć innej kolekcji.
Jeśli wykonujesz operacje na leniwie ładowanych zależnościach to hibernate je podciągnie w locie. Powinno pomóc chyba, że wychodzisz z transakcji i tam próbujesz pobrać tego usera.

@Bruno_: set nie rozwiąże tego problemu. Chodziło mi o inne konsekwencje używania listy. Wrzuć swoją kod na repo i wtedy zobaczymy, ok?

@Bruno_: dlatego pokaż kod to nie będziemy zgadywać

@Bruno_: jeśli to metoda findAllByUser z PostServicu rzuca wyjątkiem to ja oznacz jako transakcyjna a nie metodę w repozytorium. Tak jak pisałem wyżej, to metoda w której próbujesz wydobyć leniwie ładowane pole musi być wykonana w transakcji

@Bruno_: jestem na telefonie więc nie sprawdzę tego, ale wygląda na to, że serializacja Jacksona wykonuje się nie w transakcji.
Gdybyś zrobił DTO dla tego obiektu i przepisał z encji do niego wartości w transakcji to powinno działać.
Chociaż w tym wypadku najlepiej byłoby stworzyć query z joinem żeby uniknąć problemu n+1.

Query powinno byc coś koło tego
Select p from Post p JOIN FETCH p.user u

Kurla ten wykop... Ucięło mi
where u.id=?1

Ogólnie przesyłanie encji po całym systemie to trochę słaby design. Jak zmieni Ci się encja to od razu zmieni Ci się zwracany json a to może złamać jakiś kontrakt. Powinieneś oddzielić warstwę prezentacji od biznesu i persystencji.

@Hazyl: mam w milenium i polecam. Mogę podesłać Ci kod polecający(wtedy ty i ja dostaniemy bilety do kina albo kupon empik)