- Navios
- 23 de setembro de 2026 às 14:39 UTC
- Autor
- Kamo
- Enviar
- 3677d12
findById() no LeadVendorProduct puxa seu fornecedor padrão-EAGER, que se Org próprio E o seu mercado (que volta a ser org @Inheritance( JOINED), então cada um desses lúpulos também ORG MTG para resolver o subtipo polimórfico. Medida na produção pg stat statements: uma ligação de 8 vias, ~780K chamadas em 10-21ms (~3 horas de tempo cumulativo DB), quase inteiramente individual-id lookups (`onde id=1`), não a N+1 batchable — cada chamador já tem um ID e lê na maioria dos fornecedores + seus próprios campos escalares. Adiciona dois métodos LeadVendorProductRepository e muda cada chamada findById() kamo-shared-library + securityservice para o que corresponde ao que ele realmente lê: - encontrarIsEmptyCreditFfaById: uma projeção escalar JPQL, sem uniões. - findByIdWithVendor: um @EntityGraph limitado a `vendor` (uma entidade simples, não JOINED) — seller.org e seller.market voltar como proxies não iniciados cujo id ainda é legível sem extra consulta, que é toda a org-proprietário verificação nestes chamadores sempre necessário. DEliberadamente NÃO é um @EntityGraph em seller.org ou seller.market.organization: ambos são Organização, e um gráfico de entidade que obtém associações adicionais de uma entidade de herança AJUNTA é a forma exata que tomou /leades para baixo na produção em Hibernate 6.2.13 (falta de FROM-cláusula entrada para a tabela de raiz — ver LeadAssigneeRef). Os dois ouvintes que realmente precisam do mercado organização **************** em serviço de segurança) carregar LeadMarket como um segundo, consulta ordinária em vez disso — a mesma divisão que esta base de código já usa para TeamMember. As formas JSON estão inalteradas; apenas as colunas que são lidas fora do banco de dados são alteradas.