Em 10/10/2011 15:34, Guimarães Faria Corcete DUTRA, Leandro escreveu:
> 2011/10/10 Shander Lyrio<[email protected]>:
>>
>> 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
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
