Dziedziczenie JPA @EntityGraph obejmuje opcjonalne powiązania podklas

Biorąc pod uwagę następujący model domeny, chcę załadować wszystkie Answers, w tym ich Values i ich podrzędne, i umieścić go w, AnswerDTOaby następnie przekonwertować na JSON. Mam działające rozwiązanie, ale cierpi na problem N + 1, którego chcę się pozbyć za pomocą ad-hoc @EntityGraph. Wszystkie powiązania są skonfigurowane LAZY.

@Query("SELECT a FROM Answer a")
@EntityGraph(attributePaths = {"value"})
public List<Answer> findAll();

Używając metody ad-hoc @EntityGraphw Repositorymetodzie, mogę upewnić się, że wartości są wstępnie pobierane, aby zapobiec N + 1 w Answer->Valuepowiązaniu. Chociaż mój wynik jest w porządku, jest jeszcze jeden problem N + 1, z powodu leniwego ładowania selectedskojarzenia MCValues.

Za pomocą tego

@EntityGraph(attributePaths = {"value.selected"})

kończy się niepowodzeniem, ponieważ selectedpole jest oczywiście tylko częścią niektórych Valuepodmiotów:

Unable to locate Attribute  with the the given name [selected] on this ManagedType [x.model.Value];

Jak mogę powiedzieć WZP, że próbuje pobrać selectedpowiązanie tylko w przypadku, gdy jest to wartość MCValue? Potrzebuję czegoś takiego optionalAttributePaths.

Możesz użyć tylko, EntityGraphjeśli atrybut asocjacji jest częścią nadklasy, a przez to także częścią wszystkich podklas. W przeciwnym razie EntityGraphzawsze zawiedzie z tym Exception, co aktualnie otrzymujesz.

Najlepszym sposobem na uniknięcie problemu wyboru N + 1 jest podzielenie zapytania na 2 zapytania:

Pierwsze zapytanie pobiera MCValueencje za pomocą a, EntityGraphaby pobrać powiązanie odwzorowane przez selectedatrybut. Po tym zapytaniu jednostki te są następnie przechowywane w pamięci podręcznej pierwszego poziomu Hibernacji / w kontekście trwałości. Hibernacja użyje ich podczas przetwarzania wyniku drugiego zapytania.

@Query("SELECT m FROM MCValue m") // add WHERE clause as needed ...
@EntityGraph(attributePaths = {"selected"})
public List<MCValue> findAll();

Drugie zapytanie następnie pobiera Answerbyt i używa również EntityGraphdo pobrania powiązanych Valuebytów. Dla każdego Valuepodmiotu, Hibernate będzie instancji konkretną podklasę i sprawdzić czy cache poziom 1 zawiera już obiekt dla tej klasy i podstawowej kombinacji klawiszy. W takim przypadku Hibernacja używa obiektu z pamięci podręcznej 1. poziomu zamiast danych zwróconych przez zapytanie.

@Query("SELECT a FROM Answer a")
@EntityGraph(attributePaths = {"value"})
public List<Answer> findAll();

Ponieważ już pobraliśmy wszystkie MCValuejednostki z powiązanymi selectedjednostkami, teraz otrzymujemy Answerjednostki z zainicjowanym valuepowiązaniem. A jeśli powiązanie zawiera MCValuebyt, jego selectedpowiązanie również zostanie zainicjowane.

Nie wiem, co tam robi Spring-Data, ale aby to zrobić, zwykle musisz użyć TREAToperatora, aby uzyskać dostęp do sub-asocjacji, ale implementacja dla tego operatora jest dość błędna. Hibernacja obsługuje niejawny dostęp do właściwości podtypu, który byłby tutaj potrzebny, ale najwyraźniej Spring-Data nie obsługuje tego poprawnie. Polecam rzucić okiem na Blaze-Persistence Entity-Views , bibliotekę, która działa na bazie JPA, która pozwala mapować dowolne struktury na podstawie modelu encji. Możesz zmapować swój model DTO w sposób bezpieczny dla typu, również w strukturze dziedziczenia. Widoki encji dla Twojego przypadku użycia mogą wyglądać następująco

@EntityView(Answer.class)
interface AnswerDTO {
  @IdMapping
  Long getId();
  ValueDTO getValue();
}
@EntityView(Value.class)
@EntityViewInheritance
interface ValueDTO {
  @IdMapping
  Long getId();
}
@EntityView(TextValue.class)
interface TextValueDTO extends ValueDTO {
  String getText();
}
@EntityView(RatingValue.class)
interface RatingValueDTO extends ValueDTO {
  int getRating();
}
@EntityView(MCValue.class)
interface TextValueDTO extends ValueDTO {
  @Mapping("selected.id")
  Set<Long> getOption();
}

Dzięki wiosennej integracji danych zapewnianej przez Blaze-Persistence możesz zdefiniować takie repozytorium i bezpośrednio wykorzystać wynik

@Transactional(readOnly = true)
interface AnswerRepository extends Repository<Answer, Long> {
  List<AnswerDTO> findAll();
}

Wygeneruje zapytanie HQL, które wybiera tylko to, co zostało zamapowane, AnswerDTOco jest podobne do następującego.

SELECT
  a.id, 
  v.id,
  TYPE(v), 
  CASE WHEN TYPE(v) = TextValue THEN v.text END,
  CASE WHEN TYPE(v) = RatingValue THEN v.rating END,
  CASE WHEN TYPE(v) = MCValue THEN s.id END
FROM Answer a
LEFT JOIN a.value v
LEFT JOIN v.selected s

Mój najnowszy projekt wykorzystywał GraphQL (pierwszy dla mnie) i mieliśmy duży problem z zapytaniami N + 1 i próbowałem zoptymalizować zapytania, aby łączyć się tylko dla tabel, gdy są one wymagane. Uważam, że Cosium / spring-data-jpa-entity-graph jest niezastąpiony. Rozszerza JpaRepositoryi dodaje do zapytania metody przekazywania wykresu encji. Następnie można budować dynamiczne wykresy encji w czasie wykonywania, aby dodać lewe sprzężenia tylko dla potrzebnych danych.

Nasz przepływ danych wygląda mniej więcej tak:

1. Odbierz żądanie GraphQL
2. Analizuj zapytanie GraphQL i konwertuj na listę węzłów grafu encji w zapytaniu
3. Utwórz wykres encji z wykrytych węzłów i przekaż do repozytorium w celu wykonania

Aby rozwiązać problem __typenameniewłączania niepoprawnych węzłów do wykresu encji (na przykład z graphql), stworzyłem klasę narzędziową, która obsługuje generowanie wykresu encji. Klasa wywołująca przekazuje nazwę klasy, dla której generuje wykres, który następnie sprawdza poprawność każdego węzła na wykresie względem metamodelu obsługiwanego przez ORM. Jeśli węzeł nie znajduje się w modelu, usuwa go z listy węzłów wykresu. (Ta kontrola musi być rekurencyjna i sprawdzać także każde dziecko)

Zanim to znalazłem, wypróbowałem projekcje i każdą inną alternatywę zalecaną w dokumentach Spring JPA / Hibernate, ale nic nie wydawało się rozwiązać problemu elegancko lub przynajmniej z dużą ilością dodatkowego kodu

Edytowane po twoim komentarzu:

Przepraszam, nie zastanawiałem się nad problemem w pierwszej rundzie, problem pojawia się przy uruchomieniu danych wiosny, nie tylko podczas próby wywołania findAll ().

Możesz teraz nawigować po pełnym przykładzie, który możesz pobrać z mojego github: https://github.com/bdzzaid/stackoverflow-java/blob/master/jpa-hibernate/

Możesz łatwo odtworzyć i naprawić swój problem w tym projekcie.

W rzeczywistości dane Spring i hibernacja nie są w stanie domyślnie określić „wybranego” wykresu i należy określić sposób zbierania wybranej opcji.

Najpierw musisz zadeklarować NamedEntityGraphs klasy Answer

Jak widać, istnieją dwa NamedEntityGraph dla wartości atrybutu klasy Answer

• Pierwszy dla wszystkich Wartość bez określonego związku do załadowania

• Drugi dla konkretnej wartości Multichoice . Jeśli go usuniesz, odtworzysz wyjątek.

Po drugie, musisz być w kontekście transakcyjnym answerRepository.findAll (), jeśli chcesz pobierać dane typu LAZY

@Entity
@Table(name = "answer")
@NamedEntityGraphs({
    @NamedEntityGraph(
            name = "graph.Answer", 
            attributeNodes = @NamedAttributeNode(value = "value")
    ),
    @NamedEntityGraph(
            name = "graph.AnswerMultichoice",
            attributeNodes = @NamedAttributeNode(value = "value"),
            subgraphs = {
                    @NamedSubgraph(
                            name = "graph.AnswerMultichoice.selected",
                            attributeNodes = {
                                    @NamedAttributeNode("selected")
                            }
                    )
            }
    )
}
)
public class Answer
{

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(updatable = false, nullable = false)
    private int id;

    @OneToOne(cascade = CascadeType.ALL)
    @JoinColumn(name = "value_id", referencedColumnName = "id")
    private Value value;
// ..
}