Dein Endpoint setzt hunderte Queries pro Request ab. Wie kommt es dazu mit JPA und wie behebst du es?

Das ist das N-plus-eins-Problem: eine Query lädt die Parent-Zeilen, und dann löst jeder Zugriff auf eine lazy Assoziation eine weitere Query pro Zeile aus. Behebe es, indem du die Assoziation in derselben Query mit einem Join Fetch oder einem Entity Graph mitlädst, indem du eine Batch Fetch Size setzt, damit Hibernate Assoziationen in Gruppen lädt, oder indem du direkt in ein DTO projizierst, das nur die benötigten Spalten hat. Halt Assoziationen standardmäßig lazy und lad pro Use Case gezielt eager.

Das ist N plus eins. Ich lade eine Seite Bestellungen in einer Query, dann greift der Serializer bei jeder auf order.getItems zu, und weil die Assoziation lazy ist, geht Hibernate für jede einzelne Bestellung erneut los. Aus zwanzig Bestellungen werden einundzwanzig Queries, und es fällt erst mit echten Daten auf. Der erste Fix ist, alles Nötige in einem Rutsch zu laden, entweder eine Query mit Join Fetch oder ein benannter Entity Graph auf der Repository-Methode, damit die Items zusammen mit den Parents kommen. Brauche ich zwei getrennte Collections, joine ich nicht beide, weil das die Zeilen zu einem kartesischen Produkt vervielfacht; stattdessen setze ich eine Batch Fetch Size, damit Hibernate sie in Batches von, sagen wir, fünfzig mit einer in-Klausel lädt, das sind zwei Queries statt hundert. Oft ist die eigentliche Antwort, dass der Endpoint gar keine Entities braucht, dann projiziere ich direkt in ein DTO mit genau den benötigten Spalten. Was ich nicht mache, ist das Mapping auf eager umzustellen, denn das repariert einen Endpoint und verlangsamt jeden anderen. Ehrlich halte ich mich, indem ich Query-Anzahlen in einem Integrationstest prüfe.