- Spegnimento
- 23 settembre 2026 alle ore 14:39 UTC
- Autore
- Kamo
- Impegno
- 3677d12
findById() su LeadVendorProduct tira il suo fornitore di default-EAGER, che di per sé fa ansioso proprio org E il suo mercato (che aggrappa ITS org di nuovo) — e l'organizzazione è @Inheritance (JOINED), così ogni uno di quei hops anche esterna-joins ORG MTG per risolvere il sottotipo polimorfico. Misurato nella produzione pg stat statements: un raccordo a 8 vie, ~780K chiama a 10-21ms (~3 ore di tempo cumulativo DB), quasi interamente single-id lookups (`dove id=$1`), non un batchable N+1 — ogni chiamante ha già un id e legge alla maggior parte dei fornitori + i suoi campi scalari. Aggiunge due metodi magra LeadVendorProductRepository e passa ogni ricercaById() caller in kamo-shared-library + servizio di sicurezza a quello che corrisponde a quello che effettivamente legge: - findIsEmptyCreditFfaById: una proiezione scalare JPQL, nessun partecipa affatto. - findByIdWithVendor: un @EntityGraph limitato a `vendor` (una entità normale, non-JOINED) — vendor.org e vendor.market torna come proxy non inizializzati il cui id è ancora leggibile senza alcun extra query, che è tutti i controlli di org-ownership in questi chiamanti mai necessari. Deliberatamente NON un @EntityGraph in vendor.org o vendor.market.organization: entrambi sono Organizzazione, e un grafico di entità che fetches ulteriori associazioni fuori un'entità JOINED-inheritance è la forma esatta che ha preso /leads giù in produzione su Hibernate 6.2.13 (che manca voce per la tabella radice — vedere LeadAssigneeRef). I due chiamanti che hanno veramente bisogno del mercato organizzazione Carica LeadMarket come secondo, query ordinaria invece — la stessa divisione questo codebase utilizza già per TeamMember. Le forme JSON sono invariate; solo quali colonne vengono lette dal database modificato.