Executando verificação de segurança...
1

Dúvida: Devo ou não continuar meu projeto com a linguagem que escolhi ?

Opa, a minha situação é a seguinte, estou desenvolvendo um projeto web usando Java Spring Boot, JPA e Hibernate, o meu grande problema está sendo em relação ao soft delete que decidi implementar que está me gerando muita dor de cabeça, estou conseguindo deletar registros atribuindo uma data a coluna deleted_at, porém, não estou conseguindo filtrar os registros para que nenhum excluído venha para o meu sistema. A única solução que encontrei para isso é usar o @Where, porém, não quero usa-lo pois sei da dificuldade de trazer os registros deletados para o meu sistema em uma análise de métricas por exemplo.

Já tentei fazer interceptadores de query mas não consegui, nem usando o ChatGPT, nem lendo a documentação do Hibernate.

Estou com esse problema desde que começei a codar o sistema, porém só agora que vi realmente a necessidade de não retornar os registros deletados. Estou considerando mudar a linguagem que estou fazendo meu backend por conta da falta de praticidade do JPA e Hibernate em relação ao soft delete.

Aceito quaisquer sugestões sobre como implementar essa feature ou sobre mudança de linguagem. Agradeço desde já

Carregando publicação patrocinada...
2

Olá, Lucas. O tradeoff de utilizar soft delete, é ter que aplicar uma cláusula "where" para filtrar resultados. Posso te garantir que todo ORM que implementa isso, faz exatamente o que você mencionou que não gostaria de fazer. Mesmo que não veja, está por "debaixo dos panos", não se engane.
Recomendo seguir com seus planos.
Bom trabalho ;)

1

E como eu conseguiria buscar dados já deletados quando eu precisar fazer métricas? conheçe alguma maneira de contornar isso ?

O problema é que eu já vi em vários lugares pessoas recomendando não utilizar o @Where, então ainda fico meio que com um pé atrás

1

Olha, o que tu pode fazer é criar um repository só para lidar com as métricas e nesse repository só retornar os dados deletados. Ou simplesmente criar um método para lidar com isso no seu repository já existente. Ou usar um builder para compor as estruturas de especialização da sua query.
Há várias alternativas e em todas elas, o "where" vai existir.
Eu não trabalho com Spring Boot, então não sei se há alguma annotation ou trait que resolva isso pra ti. Porém, mesmo que não veja, o "where" estará lá.

1
1

Sem ver o código fica difícil dar mais detalhes, mas enfim, não consigo ver a dificuldade.

Se não quer trazer os registros deletados, precisa de um WHERE deleted_at IS NULL. Se quer só os deletados, WHERE deleted_at IS NOT NULL (ou só os que foram deletados depois de determinada data, WHERE deleted_at > data e assim por diante). E se quiser todos (deletados e não deletados), não precisa do WHERE.

Mesmo se mudar de linguagem/framework/lib/ferramenta, vai precisar fazer isso, não tem como escapar. Mas sinceramente, não acho que isso justifica mudar de linguagem. É uma situação relativamente comum, que a maioria dos - senão todos os - frameworks conseguem tratar sem problemas.

Por fim, não sei se é exatamente o seu caso, mas em uma busca rápida encontrei isso, talvez ajude.


Na verdade eu voltaria alguns passos e analisaria se vc precisa mesmo de soft delete. Pois nem sempre é necessário: como tudo em computação, tem prós e contras, então o ideal é primeiro avaliar se precisa mesmo (caso já tenha feito essa análise, pode ignorar este parágrafo).

1

Compreendo como fazer o Where para isso, o problema é deixar isso genérico e escalável, já que colocar a clausula Where em todos os meus selects pode ser trabalhoso e até perigoso caso eu esqueça de colocar em algum.

A anotação @WHERE do hibernate aplica uma clausula where para toda query que envolve a classe que recebeu a anotação. Não queria usar ela pois é muito difícil ou até impossível realizar uma query sem o próprio hibernate inserir a clausula, fazendo com que eu NUNCA consiga realizar uma query para buscar os registros deletados

Já analisei meu caso e realmente acho melhor usar o soft delete

1

Uma opção é, em vez do soft delete, usar uma tabela de histórico.

Aí quando deletar, na verdade você move o registro pro histórico. Ou seja, lá só vai ter os deletados, e na tabela original os não deletados.

Ou se quiser continuar com soft delete, simplesmente não use a anotação e lembre de colocar um where em todas as queries. Não tem jeito, e assim como disseram acima, não sei qual é o problema. É tão comum isso...

1
1

não quero usa-lo pois sei da dificuldade de trazer os registros deletados para o meu sistema em uma análise de métricas por exemplo

Não trabalho com Java atualmente, mas independente disso não entendi qual seria o problema de usar um where na aplicação. A cláusula where é uma das coisas mais comuns que usamos quando trabalhamos com banco de dados, qual é o problema por trás disso?

Mudar de linguagem

Se você for mudar de linguagem em qualquer dificuldade de arquitetura ou de biblioteca que encontrar, você quase nunca vai conseguir entregar um projeto. Se você está usando ORM e Spring Boot, é bem provável que está fazendo um projeto ao estilo Data Driven, CRUD ou coisa parecida, e nesses casos qualquer linguagem das mais populares vai atender perfeitamente (inclusive Java) o que muda é sua habilidade com ela.

Existem algumas situações em que mudar de linguagem ou reescrever um programa pode fazer sentido, mas pelo que vi da sua pergunta esse não é o caso para o seu projeto.

1

O meu problema nã é com usar o where do banco de dados, mas sim a anotação WHERE do hibernate, da qual aplica uma clausula where para toda query que envolve a classe que recebeu a anotação. Não queria usar ela pois é muito difícil ou até impossível realizar uma query sem o próprio hibernate inserir a clausula, fazendo com que eu NUNCA consiga realizar uma query para buscar os registros deletados

0

Isso nao tem nada a ver com o Hibernate. Qualquer ORM será assim

Eu acho que uma solução boa para isso é criar uma VIEW no banco de dadoscom o "where delete is not null" E aí você mapeia no Hibernate essa VIEW e passa a fazer as consultas nela

0

Pra facilitar, não seria melhor criar um atributo booleano deletado? E ao deletar você setaria ele como True e facilitaria suas buscas?
A assinatura do método no Repository:
public List<Model> findAllByDeletadoFalse();

Ou então, se deleted_at salvar null:
public List<Model> findAllByDeletedAtIsNull();

1

Sim, eu consigo fazer uma query filtrando os excluidos, porém, preciso deixar isso genérico e escalável, já que colocar a clausula where em todos os meus selects seria trabalhoso e perigoso em casos de esquecimento

1
1