- Enviado
- 23 de setembro de 2026 às 14:39 UTC
- Autor
- Kamo
- Confirmação
- c4924af
Duas correções relacionadas ao MemberRightsAppliedService, ambas no mesmo arquivo: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * incondicionalmente suprimidas e reinseridas todas as linhas de direitos aplicados de um membro, sempre que Correram. O MemberRightsBackfillService do SecurityService chama o caminho org-wide para EVERY org on TODO pod boot (uma auto-cura, por design — veja seu próprio javadoc), e o recompute é idempotent: uma bota em estado estacionário re-deriva o conjunto idêntico. Medida na produção pg stat states: ~12.7M INSERTs contra uma tabela ~30K-row — cerca de 300 reescritas na tabela completa, uma por boot, quase Todos eles a escrever exactamente o que já lá estava. Ambos os métodos agora diff o conjunto recém-computado contra o que member rights applied já possui (uma leitura a granel para um bloco inteiro) e apenas limpar + reescrever os membros cujos direitos na verdade Difere. Uma bota no-op agora custa uma leitura e zero escreve. 2. calcular os direitos de membro (o núcleo tanto do caminho de escrita acima como do somente leitura computMemberRights SessionRefreshController pesquisas em cada atualização de sessão) walk member.getRoles(), ****************job-title roles()/getRights() e member.getRights() como coleções preguiçosas separadas — além de mais uma carga preguiçosa por função distinta, para os direitos próprios desse papel. Não consolidado por membro. Seis novos campos de repositório opcional (Repositório do MemberRole,DepartmentRoleRepository, Department RightRepository, JobTitleRoleRepository, JobTitleRightRepository, MemberRightRepository — o primeiro e o último já existiam) substituir essas cargas preguiçosas por um número fixo e reduzido de volumes Consultas, cada uma com direitos próprios de um papel. NÃO deliberadamente um @EntityGraph enraizado em Membro/Membro da equipe: ambos são @Inheritance(JOINED), e um gráfico de entidade que busca mais associações fora de uma entidade unida é a forma exata que tomou / lidera para baixo na produção em Hibernate 6.2.13 (falta de entrada de linha FROM para a tabela raiz — ver LeadAsigneeRef). Cada novo repositório está enraizado na entidade CHINLD (nenhuma das quais carrega @Inheritance) e filtrado pela identificação dos pais. Um campo EntityManager com @PersistenceContext foi tentado primeiro e revertido: é processado por O pós-processador JPA da Spring sempre que o Spring-orm está no classpath, então um novo manualmente serviço em um contexto sem EntityManagerFactory bean (SignInReadRetry Mola laminada à mão contexto, que exerce @RetryOnDbConflito através de um proxy AOP real) falhou BEAN CRIAÇÃO Claro. Os campos opcional-repositório degradam-se da mesma forma aplicadaModelResolver já fez: @Autowired(necessário = false) os deixa nulos sem feijão desse tipo, e os seis ajudantes caem voltar ao caminho de carga preguiçosa original, inalterado, em todos os testes existentes. SessionRefreshController mantém a computação ao vivo (não do instantâneo persistido) — esse endpoint's todo o ponto é "o que é verdade agora", que é explicitamente nem sempre o que foi passado persistiu.