O que não ajuda, atrapalha…
Trabalhei esses últimos dias fazendo uma otimização de uma rotina escrita em C# e que usava NHibernate. Uma das mudanças que fiz foi fazer um bulk delete de uma certa entidade. Quis o destino que eu encontrasse um método delete com uma assinatura que recebia uma query. Perfeito!
Fiz a minha parte:
sessao.Delete("FROM Ocorrencia WHERE ...");
Não é que o maldito NHibernate ao invés de simplesmente criar a query de remoção, executa uma query de consulta, monta todos as entidades (no caso, Ocorrencia) e depois dá delete de um por um?
Por que diabos alguém em seu juízo perfeito escreveria um método tão estúpido quanto esse? Se eu já quero apagar esses objetos porque carrega-los na memória, consumindo o meu já escasso tempo de processamento?
Fica a lição: NÃO PROGRAME POR COINCIDÊNCIA. Não é apenas porque um método tem a assinatura perfeita que ele vai ser a solução do seu problema. LEIA A DOCUMENTAÇÃO. Certifique-se que está fazendo a coisa certa, ou caso contrário você vai se dar muito mal.
April 15th, 2010 - 23:47
Borba,
ele reescreve a consulta provavelmente (nao conheco o nhibernate mas julgando pela versao java) pra remover/invalidar o que for necessário na sessao e cache (se configurada).
May 12th, 2010 - 15:48
Entendo e concordo. Faz sentido que o nhibernate precise saber o que foi deletado para poder refletir essa mudança no session. O problema é que um método que faz isso não é claro nem útil. No hibernate (versão java) existe opção explícita através do hql para fazer bulk update/delete, que inclusive não afeta o que está na memória (sessions e caches). Faz o que deveria fazer. De qualquer forma a moral da história é que a gente não deve apenas se confiar na assinatura do método. Temos que descobrir o que ele realmente faz antes de sair usando…
July 13th, 2010 - 22:24
Faz tempo que queria ter deixado este comentário: Não podia concordar mais com esse seu comentário! Tenho a impressão que a primeira vez que li seu post não entendi que era isso que você queria expressar (na verdade já tinha esse último parágrafo?)… mas queria inclusive acrescentar uma bobeira bem comum nas linhas dessa que você descreveu de menosprezar a documentação: “Não prestar atenção ao que é o que NÃO É THREADSAFE” … meu amigo já vi gente compartilhar SimpleDateFormat entre threads no Java e simplesmente “volta e meia” aparecia um ano 1900 em produção… dá pra imaginar o trabalho pra descobrir o que era né?
abs!
August 10th, 2010 - 11:34
Já tinha o último parágrafo sim. Um outro exemplo é na biblioteca padrão do C no método strtok. Esse exemplo faz uma ligação com os posts sobre o paradigma funcional (http://borba.blog.br/2010/04/porque-linguagens-funcionais-sao-importantes e http://borba.blog.br/2010/07/por-que-voce-precisa-reaprender-linguagens-funcionais). Funções sem efeito colateral são mais fáceis de ser entendidas e usadas, mesmo em ambiente multithread.