- Expediere
- 23 septembrie 2026 la 14:39 UTC
- Autor
- Kamo
- Comite
- 3677d12
findById() on LeadVendorProduct pulls its default-EAGER vendor, which itself eager-fetches its own org AND its market (which eager-fetches ITS org again) — and Organization is @Inheritance(JOINED), so every one of those hops also outer-joins ORG_MTG to resolve the polymorphic subtype. Measured in production pg_stat_statements: an 8-way join, ~780K calls at 10-21ms (~3 hours cumulative DB time), almost entirely single-id lookups (`where id=$1`), not a batchable N+1 — each caller already has one id and reads at most vendor + its own scalar fields. Adds two lean LeadVendorProductRepository methods and switches every findById() caller in kamo-shared-library + securityservice to the one that matches what it actually reads: - findIsEmptyCreditFfaById: a scalar JPQL projection, no joins at all. - findByIdWithVendor: an @EntityGraph limited to `vendor` (a plain, non-JOINED entity) — vendor.org and vendor.market come back as uninitialized proxies whose id is still readable with no extra query, which is all the org-ownership checks in these callers ever needed. Deliberately NOT an @EntityGraph into vendor.org or vendor.market.organization: both are Organization, and an entity graph that fetches further associations off a JOINED-inheritance entity is the exact shape that took /leads down in production on Hibernate 6.2.13 (missing FROM-clause entry for the root table — see LeadAssigneeRef). The two callers that genuinely need the market's organization **************** in securityservice) load LeadMarket as a second, ordinary query instead — the same split this codebase already uses for TeamMember. JSON shapes are unchanged; only which columns get read off the database changed.