Em 10/10/2011 15:34, Guimarães Faria Corcete DUTRA, Leandro escreveu: > 2011/10/10 Shander Lyrio<shan...@nucleo45.com.br>: >> >> Ele não seleciona, verifica no objeto que ainda está em memória > > E se o objeto não estiver em memória? > > Colocando em outras palavras, fiquei com a impressão de que ele fará o > pior possível, trará tudo em memória antes de fazer qualquer operação? > > Depois o SQL é que é lento…
Sua impressão está errada. Um objeto criado em memória em Java é algo como: public class Cliente{ @id private int chaveprimaria; @Column private String cliente; ... gets e sets... } Cliente joao = new Cliente(); Não há necessidade de consulta no banco de dados, o objeto está em estado detached e portanto, quando for persistido (gravado no banco de dados), o valor passado no campo chaveprimaria será nextval('chaveprimeira'), algo como insert into clientes(chaveprimaria, cliente) values(nextval('chaveprimaria'), ?) returning chaveprimaria; Se a consulta retornar ok, então o campo chaveprimaria do objeto é atualizado e o objeto muda seu estado para managed. Se, por outro lado, você populou um objeto baseado em uma busca no banco de dados, então seu estado já é managed, portanto, não é necessária verificação de chave primária preenchida ou não. Este é o modo de funcionamento do SqlAlchemy (Python), acredito que também seja a forma do EclipseLink e Hibernate (Java) que são implementações da JPA do Java. Um projeto com milhares de cabeças pensantes trabalhando e melhorando-o por anos dificilmente vai se prestar a fazer as coisas da pior maneira possível. ORM é apenas uma ferramenta, obviamente não serve para qualquer tipo de trabalho, mas é uma ferramenta, que em muitos cenários (eu diria maioria) tem grande utilidade, nós não deveríamos ser alérgicos a ela. Um detalhe importante: o SqlAlchemy utiliza "returning" se o banco de dados utilizado tiver esta opção ou algo que se assemelhe, caso contrário, vão primeiro gerar uma sequência, popular o objeto e depois persistir. Ao invés de rechaçar completamente os ORM's, acredito que deveríamos auxiliá-los a trabalhar de forma melhor com os bancos de dados. Existem DBA's que ajudaram na construção dos ORM's, não foram apenas programadores, se temos condições de contribuir para que ele seja uma ferramenta ainda melhor porquê não fazemos? Para mim eles funcionam muito bem e muito rápido, e olha que eu tenho muito mais experiência com o PostGreSql do que com ORM's. Se alguém quiser contribuir com algum ORM neste sentido para que ele gere Sql's cada vez melhores para o nosso PostgreSql, o código do dialeto para PostGreSql do Hibernate está em [1] e o do SqlAlchemy está em [2]. [1] http://fwd4.me/0DSs [2] http://fwd4.me/0DSu Abraço, -- Shander Lyrio http://about.me/shander _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral