Die JPA-Vererbung @EntityGraph enthält optionale Zuordnungen von Unterklassen

In Anbetracht des folgenden Domänenmodells möchte ich alle Answers einschließlich ihrer Values und ihrer jeweiligen Unterkinder laden und in eine AnswerDTOablegen, um sie dann in JSON zu konvertieren. Ich habe eine funktionierende Lösung, aber sie leidet unter dem N + 1-Problem, das ich mithilfe eines Ad-hoc-Problems beseitigen möchte @EntityGraph. Alle Zuordnungen sind konfiguriert LAZY.

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

Mit einem Ad-hoc- Verfahren @EntityGraphfür die RepositoryMethode kann ich sicherstellen, dass die Werte vorab abgerufen werden, um N + 1 für die Answer->ValueZuordnung zu verhindern . Während mein Ergebnis in Ordnung ist, gibt es ein weiteres N + 1-Problem, da die selectedAssoziation der MCValues verzögert geladen wird .

Verwenden Sie dies

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

schlägt fehl, weil das selectedFeld natürlich nur ein Teil einiger ValueEntitäten ist:

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

Wie kann ich JPA mitteilen, dass nur dann versucht wird, die selectedZuordnung abzurufen, wenn der Wert a ist MCValue? Ich brauche so etwas optionalAttributePaths.

Sie können ein nur verwenden, EntityGraphwenn das Zuordnungsattribut Teil der Oberklasse und damit auch Teil aller Unterklassen ist. Andernfalls schlägt das EntityGraphimmer mit dem fehl Exception, was Sie aktuell erhalten.

Der beste Weg, um Ihr N + 1-Auswahlproblem zu vermeiden, besteht darin, Ihre Abfrage in zwei Abfragen aufzuteilen:

Die erste Abfrage ruft die MCValueEntitäten mit a ab EntityGraph, um die durch das selectedAttribut zugeordnete Zuordnung abzurufen . Nach dieser Abfrage werden diese Entitäten im Cache der ersten Ebene von Hibernate / im Persistenzkontext gespeichert. Der Ruhezustand verwendet sie, wenn das Ergebnis der zweiten Abfrage verarbeitet wird.

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

Die zweite Abfrage ruft dann die AnswerEntität ab und verwendet eine EntityGraph, um auch die zugeordneten ValueEntitäten abzurufen . Für jede ValueEntität instanziiert Hibernate die spezifische Unterklasse und prüft, ob der Cache der ersten Ebene bereits ein Objekt für diese Kombination aus Klasse und Primärschlüssel enthält. In diesem Fall verwendet Hibernate das Objekt aus dem Cache der ersten Ebene anstelle der von der Abfrage zurückgegebenen Daten.

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

Da wir bereits alle MCValueEntitäten mit den zugeordneten selectedEntitäten abgerufen haben, erhalten wir jetzt AnswerEntitäten mit einer initialisierten valueZuordnung. Wenn die Zuordnung eine MCValueEntität enthält , selectedwird auch die Zuordnung initialisiert.

Ich weiß nicht, was Spring-Data dort tut, aber um dies zu tun, müssen Sie normalerweise den TREATOperator verwenden, um auf die Unterzuordnung zugreifen zu können, aber die Implementierung für diesen Operator ist ziemlich fehlerhaft. Hibernate unterstützt den impliziten Zugriff auf Subtyp-Eigenschaften, den Sie hier benötigen würden, aber anscheinend kann Spring-Data dies nicht richtig handhaben. Ich kann Ihnen empfehlen, sich Blaze-Persistence Entity-Views anzusehen , eine Bibliothek, die auf JPA aufbaut und es Ihnen ermöglicht, beliebige Strukturen Ihrem Entitätsmodell zuzuordnen. Sie können Ihr DTO-Modell typsicher zuordnen, auch die Vererbungsstruktur. Entitätsansichten für Ihren Anwendungsfall könnten folgendermaßen aussehen

@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();
}

Mit der von Blaze-Persistence bereitgestellten Spring-Datenintegration können Sie ein solches Repository definieren und das Ergebnis direkt verwenden

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

Es wird eine HQL-Abfrage generiert, die genau das auswählt, was Sie in AnswerDTOder folgenden Abbildung zugeordnet haben.

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

Mein letztes Projekt verwendete GraphQL (eine Premiere für mich) und wir hatten ein großes Problem mit N + 1-Abfragen und versuchten, die Abfragen so zu optimieren, dass sie nur dann für Tabellen verknüpft werden, wenn sie benötigt werden. Ich habe festgestellt, dass Cosium / spring-data-jpa-entity-graph unersetzlich ist. Es erweitert JpaRepositoryund fügt Methoden zum Übergeben eines Entitätsdiagramms an die Abfrage hinzu. Anschließend können Sie zur Laufzeit dynamische Entitätsdiagramme erstellen, um nur für die benötigten Daten Linksverknüpfungen hinzuzufügen.

Unser Datenfluss sieht ungefähr so ​​aus:

1. GraphQL-Anfrage empfangen
2. Analysieren Sie die GraphQL-Anforderung und konvertieren Sie sie in eine Liste der Entitätsdiagrammknoten in der Abfrage
3. Erstellen Sie ein Entitätsdiagramm aus den erkannten Knoten und übergeben Sie es zur Ausführung an das Repository

Um das Problem zu lösen, dass ungültige Knoten nicht in das Entitätsdiagramm aufgenommen werden (z. B. __typenameaus graphql), habe ich eine Dienstprogrammklasse erstellt, die die Generierung des Entitätsdiagramms übernimmt. Die aufrufende Klasse übergibt den Klassennamen, für den sie das Diagramm generiert, und validiert dann jeden Knoten im Diagramm anhand des vom ORM verwalteten Metamodells. Wenn sich der Knoten nicht im Modell befindet, wird er aus der Liste der Diagrammknoten entfernt. (Diese Prüfung muss rekursiv sein und auch jedes Kind prüfen.)

Bevor ich dies fand, hatte ich Projektionen und jede andere in den Spring JPA / Hibernate-Dokumenten empfohlene Alternative ausprobiert, aber nichts schien das Problem elegant oder zumindest mit einer Menge zusätzlichen Codes zu lösen

Nach Ihrem Kommentar bearbeitet:

Ich entschuldige mich, ich habe Ihr Problem in der ersten Runde nicht verstanden. Ihr Problem tritt beim Start von Spring-Daten auf, nicht nur, wenn Sie versuchen, findAll () aufzurufen.

So können Sie jetzt navigieren. Das vollständige Beispiel kann von meinem Github abgerufen werden: https://github.com/bdzzaid/stackoverflow-java/blob/master/jpa-hibernate/

Sie können Ihr Problem in diesem Projekt einfach reproduzieren und beheben.

Tatsächlich können Spring-Daten und der Ruhezustand das "ausgewählte" Diagramm standardmäßig nicht bestimmen, und Sie müssen angeben, wie die ausgewählte Option erfasst werden soll.

Sie müssen also zuerst die NamedEntityGraphs der Klasse Answer deklarieren

Wie Sie sehen können, gibt es zwei NamedEntityGraph für das Attribut - Wert der Klasse Antwort

• Der erste für alle Wert ohne spezifische Beziehung zur Last

• Die zweite für den spezifischen Multichoice- Wert. Wenn Sie diese entfernen, reproduzieren Sie die Ausnahme.

Zweitens müssen Sie sich in einem Transaktionskontext antworten. AnswerRepository.findAll (), wenn Sie Daten vom Typ LAZY abrufen möchten

@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;
// ..
}