Exatamente isso Sergio, abstrair nem sempre é reinventar a roda, eu não tenho pra que fazer outro framework se for manter a mesma complexidade, mas eu posso criar coisas mais fáceis.
O que parece é que alguns frameworks se preocuparam tanto com sua abrangência no sentido de funcionalidades que acabaram esquecendo sua principal função que é facilitar as coisas.
[quote=tnaires]Já o Sérgio, em sua resposta, se mostrou bem mais maduro e equilibrado.
Obrigado pelo respeito.[/quote]
Ok tnaires, acho que peguei pesado realmente, peço desculpas pelo ocorrido.
Ok cara, às vezes as pessoas se desentendem, mas o importante é que elas se entendam depois. 
Vamos evitar que esse tópico seja bloqueado e continuar o assunto.
Eu nao disse que voce é obrigado a usar select dentro da query, só disse que ele tem um motivo para fazer isso, e voce disse que ele nao tinha.
Se o oracle tambem nao pensasse em transacoes que tem apenas selects, porque sera que existe o comando SET TRANSACTION READ ONLY??? E nao sei se dirty read e phatom read sao tao avancados assim.
Outra frase equivocada sobre banco de dados: “Leituras nunca são bloqueadas e nunca bloqueiam ninguém. Escritas bloqueiam apenas outras escritas.” Onde voce leu que o Oracle pensa assim? Fonte? O oracle nao tem isolation level Serializable? Nao tem level de Repetable Read? Ele nao tem Select for update? As escritas podem sim bloquear leituras, e as leituras podem bloquear TAMBEM. A
Voce falou mal da documentacao do hibernate, disse que fala coisas sem sentido, como essa de ter transacao em volta do select. Gostaria de saber se agora voce concorda que ela NAO esta errada, e que “a entrada nao esta podre”. Sei que o topico nao eh de hibernate, mas tem um monte de gente que conta com a sua credibilidade e te adimira, e nao gostaria que quem lesse suas mensagens acreditassem que “nao faz sentido um select dentro de uma query” ou que o oracle faz que escritas so bloqueiem escritas.
[quote=volnei][quote=emerleite]Eu acho que em sistemas bem simples o hibernate ajuda pra caramba. As vezes não preciso nem me preoculpar com coisas mais cascudas. Simplesmente uso @Entity as vezes @Transient e fica tudo limpinho e bem facil. Para CRUDS então vira algo trivial.
Sinceramente não to visualizando o que tem de complexo nisto.[/quote]
Ok, só que como citado XXX vezes esse tópico [size=24]NÃO É SOBRE HIBERNATE![/size][/quote]
Segundo o tópico, Hibernate foi uma reinvenção da roda. Acho então válido.
Fala Paulo, eu sei que a mensagem foi direcionada ao Sergio, mas eu acho que tá ficando um mal entendido aqui que vou tentar explicar.
O Hibernate é um excelente framework e isso é fato, oque estamos dizendo é que a transposição de JDBC para Desenvolvedor que ele promove seja questionável mas não em funcionalidade e sim em complexidade. E esse não é um problema do hibernate e sim de vários frameworks talvez eu tenha citado ele simplesmente por ser um dos mais famosos. Mas a última coisa que eu queria era questionar o hibernate.
Espero que tenha sido claro.
Abraços
E pra que trabalhar com SQL puro hoje em dia a não ser para fazer acesso a um banco pré existente com uma estrutura tosca? O iBATIS já existe para ajudar nesse tipo de problema.
E por que esse “pobre-coitado” (que termo horrível para um desenvolvedor de software. Parece uma criança inocente ) não pode aprender o hibernate? Por que não querer aprender/usar o hibernate ?
Desculpe, isso não é flame-war, eu só quero entender o que você pensa sobre isso.
[quote=emerleite]
Segundo o tópico, Hibernate foi uma reinvenção da roda. Acho então válido.[/quote]
Acho que não ficou bem claro, o hibernate não é uma reinvenção da roda, ele é uma das formas que poderia ter sido usada para abstrair o mapeamento OR, mas existem outras formas o que não podemos é achar que qualquer outra tecnologia seja reiventar a roda.
O hibernate só foi citado nesse tópico como um exemplo, não era a intenção discutir sobre o framework.
Talvez tenha então e eu te agradeço por esclarecer isso. Mas me pareceu um caso bem particular e avançado para ser o default da coisa.
http://www.wisc.edu/drmt/oratips/sess001.html (de 1997)
Concordo que não está errado, mas acho que está mais complexo do que deveria ser, ou seja, transaction em volta de select é desnecessário na grande maioria dos casos.
Sobre o Oracle, vide as fontes acima.
Como qualquer um as vezes falo besteira e estou errado/enganado sobre certos assuntos, assim como vc, um cara altamente capaz parece que estava errado em relação ao locking do Oracle. Acho que basta bons e educados argumentos para convencer as pessoas a olhar a coisa atrav
es de um novo ponto de vista.
[quote=emerleite]
E por que esse “pobre-coitado” (que termo horrível para um desenvolvedor de software. Parece uma criança inocente ) não pode aprender o hibernate? Por que não querer aprender/usar o hibernate ?
Desculpe, isso não é flame-war, eu só quero entender o que você pensa sobre isso.[/quote]
Na minha opinião, vou usar um termo mais antigo que reinventar a roda, nem Cristo agradou a todos, acha que o hibernate vai agradar??
E é assim que surgem as grandes idéias, se eu não estou contente com esse vou pensar em como poderia fazer algo melhor e quem sabe amanhã colocando mais um projeto para a comunidade.
Voce nao leu o proprio texto que mandou Sergio!!! LOGO abaixo ele deixa CLARO que ele esta falando de locks em arquivos das tabelas INTEIRAS. O livro é pro administrador unix/linux, por isso ele esta dando detalhes de file system! Nao estamos falando de file system, correto? Isolation level nada tem com file system, pouco importa como ele esta fazendo no sistema operacional! Voce simplesmente traduziu uma frase sem ler o paragrafo abaixo!!!
Vamos ao site da propria oracle, e ver um exemplo que tenha level READ COMMITTED ou maior:
Claro que um update pode travar sim outras leituras!!!
http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html
Entao cuidado com essa frase: “Leituras nunca são bloqueadas e nunca bloqueiam ninguém. Escritas bloqueiam apenas outras escritas.”" Apesar de ser como voce disse que pensa, definitivamente nao é como o Oracle pensa. Ele ate pode internamente fazer locks diferentes, ou evitar locks e depois retirar deadlocks, mas o efeito vai ser o de haver um lock.
Se o que voce esta querendo dizer eh que na maioria das aplicacoes as vezes a gente nao precisaria de tantos locks, ai eu concordo… como eh o caso la do hibernate. Sao sistemas raros que precisamos realmente evitar phantom reads
Como ja desde muito antes de inventarem Java ja falavam
Nada se inventa apenas se copia e melhora ou se “trasnforma”
ou seja reinventar algo seria como por exemplo refazer um codigo que faz amais do que o outro com as mesmas coisas
ou seja a roda, roda não importa quao nova ou antiga ela roda e se eu fizer uma roda novinha ele continua sendo roda
assim como o hibernate continua sendo Java só que serve como atalho para algumas coisas.
Não ninguem está reinventando a roda e apenas sim tentando a aprimora-la, cabe a cada um descidir se ela é melhor para fazer oque você precisa ou não.
Boa pergunta. Não sei a resposta. Porque não querer aprender Hibernate, Spring, iBatis, Mentawai, VRaptor, Struts, Tapestry, etc.
Não tenho dúvida de que quanto mais vc sabe melhor é. Problema é que o tempo é escasso e cada pessoa está num determinado nível técnico. Existem pessoas que começaram a programa em Java agora, outras que programam a uma década. Outros que conhecem SQL, outros que nunca viram SQL. E por aí vai…
O problema é que o mundo Java abusou dessa sua pergunta e criou-se a salada de frameworks. Para fazer uma aplicação web java era muito simples, bastava usar Struts, JSTL, Hibernate, C3P0, Commons Validation, Spring, Commons Email, Commons File Upload, JAAS, Tiles, Log4J, OSCache, etc. Por que não saber usar e integrar esses frameworks? Isso não colabora nem um pouco para a simplicidade e a produtividade, principalmente dos menos experientes.
vou parar de falar ja que agora todos concordam em amar o Hibernate incodicionalmente 
[quote=volnei]
Na minha opinião, vou usar um termo mais antigo que reinventar a roda, nem Cristo agradou a todos, acha que o hibernate vai agradar??[/quote]
Até concordo mas cadê os argumentos técnicos que não agradam vocês? É necessário conhecer a solução de forma profunda para tomar conclusões.
Novamente, grandes idéias surgem quando você avalia algo e cria algo melhor. Mas no caso do hibernate, o que seria tão problemático que não pudesse ser modificado/ajustado/adicionado no código deste, visto que é aberto? Esse algo melhor que você vai colocar pode ser algo que já existe, mais simples que o seu, mais testado e mais maduro. Não é melhor estudar o que já tem e se você tiver uma ídeia que seja bem diferente do que já tem, ou que não seja possível implementar em algo já existente por questões arquiteturais do core, em fim, sei lá o que, você cria novo?
[quote=Paulo Silveira]Voce nao leu o proprio texto que mandou Sergio!!! LOGO abaixo ele deixa CLARO que ele esta falando de locks em arquivos das tabelas INTEIRAS. O livro é pro administrador unix/linux, por isso ele esta dando detalhes de file system! Nao estamos falando de file system, correto? Isolation level nada tem com file system, pouco importa como ele esta fazendo no sistema operacional! Voce simplesmente traduziu uma frase sem ler o paragrafo abaixo!!!
Vamos ao site da propria oracle, e ver um exemplo que tenha level READ COMMITTED ou maior:
Claro que um update pode travar sim outras leituras!!!
http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html
[/quote]
Não Paulo, tenha a humildade de assumir que vc estava equivocado quanto a isso. Qualquer um pode estar errado sobre alguma coisa. Isso não é pecado, por favor.
Ou como eu fiz, coloque o texto, com as fontes e de preferencia cite duas fontes distintas. Eu li muito bem o parágrafo anterior e o posterior. Acho que quem não leu direito foi vc. Vou postar aqui o parágrafo seguinte que vc disse que eu não li.
E veja que a primeira fonte (sim, citei duas) [color=blue]é de 1997 e já afirmava isso[/color], sem observações ou poréns.
Vou achar mais uma fonte a esmo aqui no Google:
Fonte: http://www.adp-gmbh.ch/ora/concepts/undo.html
Mais uma fonte: http://www.burtleburtle.net/bob/other/sql.html
Isso é antigo do Oracle e ele foi o pioneiro. Acho que agora o MySQL e outros DB já possuem esse comportamento, ao meu ver, bem importante.
Acho que vc ainda não entendeu o tópico! Um exemplo é um exemplo nada mais do que um exemplo. Po pessoal relaxa, vou repetir NINGUEM TÁ QUESTIONANDO O HIBERNANTE!
É a idéia do tópico, só que nem sempre pode-se implementar algo em cima do que já existe…
Repare que o proprio site da oracle esta falando sim de writer bloquear reader. Isso é o que voce ve no final. Assim como o SELECT FOR UPDATE locka tambem. Te importa se la dentro ele fez macumba ou tirou xerox da linha a cada modificacao?
Voce esta falando da implementacao interna do Oracle. como disse ali " Ele ate pode internamente fazer locks diferentes, ou evitar locks e depois retirar deadlocks, mas o efeito vai ser o de haver um lock". Voce disse que pensa como a Oracle faz, entao voce fica anotando no mentabean todo o historico de modificacoes no objeto durante uma transacao, assim se alguem precisar ver a versao antiga (pra nao ocorrer dirty read) voce recalcula a versao antiga e a mostra, para nao ter de usar um syncrhonized em cima daquele objeto? Isso é realmente avancado e complicado, alem de gastar muita memoria, eu fico com o synchronized para obter o mesmo efeito.
Realmente interessante essa implementacao da oracle, com o objetivo de fazer os locks que precisamos, nao conhecia. Parece aqueles Log Ahead First para recuperar banco de dados do crash.
Acho que a pergunta inicial foi mal formulada. Não existe necessariamente uma relação entre reinventar a roda com abstrair a complexidade.
O problema que sempre reinventam a roda quando precisam que o framework X tenha strings azul e não verde é uma apenas uma prova que construir frameworks, ou qualquer peça de software reutilizável, é uma tarefa difícil que exige tempo e experimentação. Basta analisar os frameworks Java do começo do século e alguns que temos hoje para notar a diferença.
Falo das características fundamentais, axiomáticas até, que todo framework deve seguir: extensibilidade e poder ser composto. Notem que as duas apesar de próximas tem diferenças marcantes. Um framework extensível permite que seu comportamento seja plenamente customizavel, enquanto ao permitir ser composto, garante que ele seja, por assim dizer, apto a ser consumido por outro framework.
O Hibernate é um ótimo exemplo de como um framework deve ser construído e isso só aconteceu na versão 3.0, então não é fácil. É muito fácil construir um framework em cima do Hibernate. Por exemplo, implementar o MentaBeans com Hibernate seria muito mais simples que da forma como está. Implementar um modelo semelhante ao ActiveRecord e expor esses objetos a um interpretador de JS também é super simples, isso tudo apenas programando em cima do Hibernate.
O problema de reinventar a roda é quando os frameworks existentes foram criados pensando exclusivamente no usuário final e não que serão consumidos por outros. Isso é um erro grave que até hoje ainda é uma praga no mundo Java.
Fui lá fuçar a sua fonte no site da Oracle, por curiosidade mesmo. Doeu o cérebro, mas encontrei isso aqui na tabela que fala que o writer está bloqueando o read.
http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html
Acho que ali ele está demonstrando todos os isolations levels e como os outros bancos de dados se comportam para depois falar que o Oracle é o bom!
Não tenho certeza, mas acho que o MySQL e outros já possuem essa característica que no passado já foi o trunfo do Oracle, afinal alguma coisa tinha que justificar pagar 100 mil reais por um software. 