Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
O Portal javafree.org inicia mais uma promoção para os usuários do fórum. Quem publicar mais posts válidos (perguntas ou respostas) entre 16/4 a 13/7 levará para casa um iPad 2 de 16GB!
E ae galera blz, seguinte ah tempo ai que venho me deparando com certos tipos de consultas de banco, ah quem prefira usar HQL, outros preferem usar Criteria e Outros são amantes da Query Nativa. Bom vou citar minha breve opinião sobre cada um desses conceitos, quem quiser contribuir manda ver ai.....flw...!!!
HQL = Hibernate Query Language, tem a sintaxe parecida com a SQL, ou seja, quem consegue se dar bem com sql nao vai ter mta dificuldades para trabalhar com HQL.
Vantagens: Trabalhar diretamente com objetos, mais rápido que o uso de Criteria, bem mais facil de fazer junçao de tabelas por conta dos mapeamentos da classe, mais legível que a própia SQL e compatível com a maioria dos bancos de dados.
Desvantagens: Ter de usar um objeto do tipo org.hibernate.classic.Session, as vezes ocorrem alguns erros de objetos duplicado na sessão do hibernate, menos rápido que a Query Nativa(SQL), menos legivel em questao de código do que o uso de Criteria, não ter a cláusula UNION do sql, nesse caso teria q criar uma visão no banco de dados, mapear essa visao e fazer um hql em cima dessa visão para obter os resultados de uma UNION.
Criteria: Aos amantes de Criteria nao estou aqui para criticar, Criteria tbm trabalha com objetos e tbm acho mais legivel a nivel de código do que o HQL.
Vantagens: Ser mais legivel a nível de código, possui vários metodos implementados fazendo o papel das cláusulas do sql e do propio HQL.
Desvantagens: Menos rápido numa consulta de banco do que o HQL e a Query Nativa(SQL), alguns metodos não são compatível com alguns BDs, nao possui um metodo com a implementação de union de classes ou tabela, ou seja, irá ter q recorrer ao mapeamento da visao q eu citei acima. E não sei aconteceu só comigu mais algumas consultas mais detalhadas nao retornaram os resultados corretamente, e eu tive q recorrer ao hql e o uso do objeto org.hibernate.classic.Session as vezes ocorrendo o mesmo erro da sessão do hibernate, tendo q recorrer a outras metodos como clear do objeto session para poder inserir ou atualizar algo no bd.
Query Nativa: Use a SQL compativel com o seu bd do jeito q vc quiser e manda através de uma simples conexao JDBC com a ajuda de uma interface PreparedStatement e jah era.
Vantagens: Muito mais rapido que uma HQL e Criteria, vc pode utilizar várias funçoes compativeis com o seu bd q irá interpretar numa boa e bom para que gosta de fazer misérias com sql e deseja aproveitar no java "economizando" assim algumas linhas de código.
Desvantagens: Algumas funções soh funcionam em determinados bancos, se vc usar um convert por exemplo do sql server o firebird nao irá acessar, ai oq vai acontecer??? vc vai rodar.... ou entao vc vai ter q fazer um tratamento no seu código para usar uma sql diferente compativel para cada tipo de banco(Sistema para orgao publico acontece mto isso). Acho q soh esse exemplo basta...hehehehe
Resumindo: odeio Query Nativa, Não muito fã de Criteria e Amante da HQL.
Eh isso ai pessoal quem quiser contribuir eh soh responder...flw ai!
_________________
Att.
Everton Barros Fil 4:13 "Tudo posso naquele que me fortalece"
Eu particularmente não sou nada nada fã de usar query nativa para codificação de cosulta em banco, mas em algumas situações, é necessário. HQL ainda acho que é o melhor caminho, e com certeza em muitos projetos que tenho visto por aí, abrange mais de 80% das consultas. Criteria? Em alguma situações eu curto usar criteria, mas tudo o que se faz com ela, dá pra se fazer com HQL. Além do mais a idéia que tenho do Criteria, é que é uma tentativa de "enjambre" para os puristas que não curtem ver HQL em seu código.
Quanto ao HQL, nunca precisei de UNION, e nunca tive os outros problemas descritos (nunca precisei usar a interface 'classic', e nunca tive problemas de objetos duplicados).
Para não poluir o código java com HQL, eu só uso namedQueries. As queries são declaradas via annotations em suas respectivas entidades, mas todas elas são escritas como constantes em uma classe 'Queries'.
Quanto ao criteria, eu criei um adapter para a session do hibernate com métodos genéricos (que servem pra qualquer entidade) muito úteis, que usam Criteria (findAll(), findByExample(), findByNaturalId()). Mas do ponto de vista geral, prefiro evitar. Principalmente quando os parâmetros de consulta são de várias entidades, acho Criteria quase ilegível.
Quanto ao native query, eu só usaria se estivesse lidando com banco legado, em que há necessidade de chamar stored procedures.
Em relação a desempenho, creio que a única perda do HQL em relação a SQL nativa se refere a converter o HQL em SQL, certo? E ainda não trabalhei em um sistema onde o requisito de desempenho fosse tão grande que a conversão de HQL em SQL fosse problema.
Enfim, minha preferência é por HQL pra consultas específicas (que servem a uma entidade específica), e Criteria pra fazer 'receitas' úteis pra qualquer entidade.
Resumindo: odeio Query Nativa, Não muito fã de Criteria e Amante da HQL.
Não precisa odiar nem amar nada, basta saber oq usar em cada situação
Geralmente uso Criteria p/ queries dinâmicas, acho que se encaixa melhor em situações onde a consulta pode ter N combinações diferentes de acordo com os parâmetros de busca. Além disso a API de Criteria favorece refactoring automáticos através da IDE. Já a HQL cai melhor em queries estáticas e complexas.
_________________
Tiago Fernandez Blog | Twitter
No Criteria ou HQL é possivel usar hints de banco? Se sim, como isso é feito?
_________________
Até mais, Roberto Jundi Furutani Sun Certified Business Component Developer 1.3 Sun Certified Web Component Developer 1.4 Sun Certified Java Programmer 1.4
Resumindo: odeio Query Nativa, Não muito fã de Criteria e Amante da HQL.
Não precisa odiar nem amar nada, basta saber oq usar em cada situação
Geralmente uso Criteria p/ queries dinâmicas, acho que se encaixa melhor em situações onde a consulta pode ter N combinações diferentes de acordo com os parâmetros de busca. Além disso a API de Criteria favorece refactoring automáticos através da IDE. Já a HQL cai melhor em queries estáticas e complexas.
Interessante colocação, pois a refatoração é um ítem bastante interessante e deve ser considerado. Ponto positivo para a Criteria.
_________________
Sugestão de Livros
Criteria: a legibilidade é terrível, mas dá pra fazer algumas coisas interessantes que, ou é chato, ou não dá pra fazer com HQL, como montar queries dinâmicas e reaproveitar condições tanto para o resultado quanto para um count (com projections), coisa que é sempre necessária quando você tem listas paginadas.
HQL: beeeeem mais legível que Criteria (mais legível que SQL, mas não absurdamente), principalmente se for externalizada em um arquivo à parte (XML ou texto), porque indentar queries concatenando strings é uma bosta.
SQL: bom e velho SQL necessária quando performance é necessária. Também permite várias coisas que simplesmente são impossíveis com HQL, como outer joins de atributos (e não associações via chave). Peca na portabilidade, mas a maior parte das aplicações precisam mais de performance que portabilidade, ponto.
Obs.: se você usa JPA com Hibernate como provider, grandes são as chances de você não estar escrevendo queries portáveis, porque a especificação da JPAQL é mais limitada que HQL, em detalhes que a gente nem percebe. Por exemplo, o Hibernate permite que você passe coleções como parâmetro (numa cláusula 'in'), mas JPA não. Mas óbvio que, se você estiver usando Hibernate por baixo do JPA, vai funcionar. Só pra deixar claro que essa história de que se você usa JPA você pode trocar o Hibernate por Toplink ou OpenJPA só trocando os JARs é, como dizem, bullshit (a não ser que a sua aplicação é tão bocó que você nunca esbarrou em nenhuma extensão, claro). Portanto, use Hibernate e pronto. Pode usar a API JPA, mas tenha em mente que isso é só uma casca para o Hibernate, e não uma 'camada de independência da tecnologia de persistência', como eu já ouvi várias vezes.
Tetsuo
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Resumindo: odeio Query Nativa, Não muito fã de Criteria e Amante da HQL.
Não precisa odiar nem amar nada, basta saber oq usar em cada situação
Geralmente uso Criteria p/ queries dinâmicas, acho que se encaixa melhor em situações onde a consulta pode ter N combinações diferentes de acordo com os parâmetros de busca. Além disso a API de Criteria favorece refactoring automáticos através da IDE. Já a HQL cai melhor em queries estáticas e complexas.
Soh foi uma colocação, talvez eu tenha me empolgado na expressão..auuhauhauhauha....mas eu jah tive experiencias com as 3 situações das quais citei acima... _________________
Att.
Everton Barros Fil 4:13 "Tudo posso naquele que me fortalece"
Na minha opinião isso é algo muito pessoal, para aqueles que conhecem sql, estão acostumados com a propria estrutura de codificação, parace ser mais interessante trabalhar com HQL, visto que as limitações entre SQL e HQL se restringem a poucas funcionalidades basicamente unions e alguns problemas com coalesce e joins (como forçar um relacionamento left join entre duas tabelas que não possuem um relacionamento).
Aqui na empresa que trabalho usamos muito HQL para relatórios e alguns processos que necessitam de uma busca mais robusta e complexa.
Normalmente não carregamos objetos inteiros, pois isso acaba sendo pouco performatico, sendo que o hibernate gera um sql monstruoso que dependendo do seu ER estora o numero de colunas na clausula SELECT ou FROM, carregamos as colunas que queremos e então usamos um recurso do nosso Framework que popula os VOs.
Isso é muito pratico e produtivo para nós, em mais ou menos 3 minutos tenho uma query montada e retornando uma lista de objetos populados. gosto do HQL por essa maleabilidade com a estruturação da busca dos dados e da manipulação do resultado.
Nunca gostei de SQL/HQL por não poder ser compilada. Por várias vezes eu defendi que a HQL deveria ser uma extensão da linguagem Java. Ferramenta que poderia ser montada seguindo a mesma estrutura do AspectJ. Não facilitaria apenas consultas em bancos de dados, mas qualquer iteração sobre uma Collection.
Traduzir uma HQL em SQL é trivial. A parte de carregar VOs da HQL do hibernate é fantastica mas, obviamente, HQL é lenta. É uma pena que as HQLs não sejam implementadas diretamente no banco de dados, retornando streams de VOs ao invés de ResultSets (Nem pense em XML). Imaginem criar uma view com HQL. Será que a Oracle anda brincando com isso? Estou completamente por fora.
Sobre a portabilidade da SQL, não tive problemas com queries SQL ANSI 92. Claro, o set de instruções é reduzido mas você faz tudo que faria num Oracle, com alta performance e portabilidade.
PS: 1992? Pqp! Será que ninguém inventou nada melhor não? Já se foram 16 anos! PS2: Parabéns pelo nível da discussão galera.
_________________
Vitor Pamplona http://vitorpamplona.com @vitorpamplona
(Query) Hints no Oracle são dicas/instruções para o banco, que vão junto com o SQL disfarçados como comentários, por exemplo para indicar qual indice a ser usado.
Exemplo:
exemplo da página[url]http://www.psoug.org/reference/hints.html:
O oracle entende que um comentario iniciado com "/*+" é um "hint". Nesse exemplo para usar o os indices t1_abc e t2_abc ao executar esse query. []]
_________________ Ganhe um iPad 2 16GB na promoção do Fórum! Carlos Heuberger faxineiro do fórum [:-) crie o seu tópico; se for na área errada, pode deixar que eu arrumo! é claro que sobra menos tempo para responder... [:-( ____________________________________________________________________________________________________________ Não respondo MPs com perguntas sobre programação ou sobre Java! Por favor use o fórum! Sempre execute um printStackTrace dentro do catch "ex.printStackTrace();" Contra o abuso de IDE's no aprendizado. This posting is provided AS IS with no warranties and confers no rights.
(Query) Hints no Oracle são dicas/instruções para o banco, que vão junto com o SQL disfarçados como comentários, por exemplo para indicar qual indice a ser usado.
Ahhh, certo! Não sabia que isso eram hints
Da para tentar o Query.setComment, mas acho que não vai funcionar.
Em todo o caso, tah na hora de alguém incluir na SQL esse tipo de comando e remover esse POG da Oracle.
_________________
Vitor Pamplona http://vitorpamplona.com @vitorpamplona
No Criteria ou HQL é possivel usar hints de banco? Se sim, como isso é feito?
Que eu saiba o hql nao suportar hints.
É não encontrei nada que possa inserir os hints corretamente. Pelo menos no Oracle esses hints ajudam bastante a diminuir os custos de acesso aos dados.
_________________
Até mais, Roberto Jundi Furutani Sun Certified Business Component Developer 1.3 Sun Certified Web Component Developer 1.4 Sun Certified Java Programmer 1.4
Nunca gostei de SQL/HQL por não poder ser compilada. Por várias vezes eu defendi que a HQL deveria ser uma extensão da linguagem Java.
Se formos p/ os lados da JPQL, talvez uma abordagem interessante seja o uso de uma DSL interna. Um bom exemplo de implementação é o LIQUidFORM.
_________________
Tiago Fernandez Blog | Twitter
@Vitor: Parece uma boa idéia, vc tem um link detalhando como isso funciona? No caso de abrir esse código numa IDE, imagino que seja preciso um plugin p/ conseguir compilar e rodar isso. Sendo assim, vc não acha que partir p/ uma DSL interna seja uma solução mais simples? Valeu!
_________________
Tiago Fernandez Blog | Twitter
@Vitor: Parece uma boa idéia, vc tem um link detalhando como isso funciona? No caso de abrir esse código numa IDE, imagino que seja preciso um plugin p/ conseguir compilar e rodar isso. Sendo assim, vc não acha que partir p/ uma DSL interna seja uma solução mais simples? Valeu!
Eu acredito que as alterações na linguagem seriam pequenas, pois é possível desmontar uma instrução select/from/where em um conjunto de instruções padrão do java. A vantagem para o desenvolvedor é um código mais curto, legível e uma ferramenta de query compilada junto com o programa. Com a compilação, a refatoração poderia ser feita também nestas instruções novas.
Sobre as IDEs, da mesma forma que existem plugins para AspectJ, novos plugins poderiam suportar esta nova linguagem.
Claro que eu preferiria que isto fosse adicionado a especificação do Java junto com uma primitiva para o BigInteger e BigDecimal. Mas, como a linguagem não evolui, isso provavelmente não vai acontecer.
Update: Agora que me toquei de uma coisa. O select poderia permitir a VM paralelizar automaticamente o teu código. Exelente para arquiteturas multi-core. Isso seria bombástico.
_________________
Vitor Pamplona http://vitorpamplona.com @vitorpamplona
Olha eu sou fãn de carterinha do Hibernate, acho ele muinto prático e seguro. Tenho total confiança nele, e utilizo ele em todos sempre que possível, o cod. fica muinto mais civilizado!
Sei que o topico e meio velho, mas tenho o seguinte problema. Uso hqls a bastante tempo e sao muito boas no modo geral, digamos entre 80-90% dos casos, mas o que da raiva e que algumas situacoes ele ingessa. Exemplo: No trabalho tem um Bean "NotaFiscal" o problema e que ele tem varios atributos que sao collections e nesse caso nao da para fazer join fetch com todos eles pois o hibernate gera uma SQL monstruosa e lenta. Percebi que fazendo tres selects separadas e juntando no objeto fica bem mais performatico, porem, ocorre um erro pq ele 'detecta' que as collections estao corrompidas(foram populadas manualmente). Existe uma maneira de fazer com que o hibernate ignore isso em tempo de execucao?
Sei que o topico e meio velho, mas tenho o seguinte problema. Uso hqls a bastante tempo e sao muito boas no modo geral, digamos entre 80-90% dos casos, mas o que da raiva e que algumas situacoes ele ingessa. Exemplo: No trabalho tem um Bean "NotaFiscal" o problema e que ele tem varios atributos que sao collections e nesse caso nao da para fazer join fetch com todos eles pois o hibernate gera uma SQL monstruosa e lenta. Percebi que fazendo tres selects separadas e juntando no objeto fica bem mais performatico, porem, ocorre um erro pq ele 'detecta' que as collections estao corrompidas(foram populadas manualmente). Existe uma maneira de fazer com que o hibernate ignore isso em tempo de execucao?
Cara o ideal seria vc criar um novo tópico, falando sobre o seu problema, a ideia desse tópico e discutir sobre as funcionalidades e desempenho das consultas ao banco e não resolver problemas. Crie um novo tópico. _________________
Att.
Everton Barros Fil 4:13 "Tudo posso naquele que me fortalece"
Poderia utilizar-se deste código para fazer o únion:
Claro que você precisaria disparar a execução de duas consultas no banco, para utilizar este método.
Outro código que pode ser utilizado com facilidade na mesma situação
Das duas formas, teremos duas collections, se tornando uma e sem duplicação.
Claro que dependendo da situação seja necessário sobrescrever o equals e o hashCode das entidades
Aproveitando para ressurgir das cinzas....
Minha opinião eh q isso nao seria viável, pois teria q disparar 2 consultas ao banco eh isso mto mais demorado do que vc criar uma visão e mapea-la, assim vc faria uma consulta em cima da visao, sem precisar disparar duas ou ateh mesmo mais consultas no banco, e em um caso como este onde vc tem q disparar 2 consultas provavelmente vc tem que juntar os objetos do qual vc irá precisar de mais uma lista e ai vai mais um laço, e isso irá consumir mais memória do que o assunto inicial da UNION, ou seja, uma simples visão mapeada resolve, se contar a perfomance(consumo de memória x tempo) e também código mais limpo e enxuto.
_________________
Att.
Everton Barros Fil 4:13 "Tudo posso naquele que me fortalece"
ebarros Offline
Posts: 2342
E ae galera blz, seguinte ah tempo ai que venho me deparando com certos tipos de consultas de banco, ah quem prefira usar HQL, outros preferem usar Criteria e Outros são amantes da Query Nativa. Bom vou citar minha breve opinião sobre cada um desses conceitos, quem quiser contribuir manda ver ai.....flw...!!!
HQL = Hibernate Query Language, tem a sintaxe parecida com a SQL, ou seja, quem consegue se dar bem com sql nao vai ter mta dificuldades para trabalhar com HQL.
Vantagens: Trabalhar diretamente com objetos, mais rápido que o uso de Criteria, bem mais facil de fazer junçao de tabelas por conta dos mapeamentos da classe, mais legível que a própia SQL e compatível com a maioria dos bancos de dados.
Desvantagens: Ter de usar um objeto do tipo org.hibernate.classic.Session, as vezes ocorrem alguns erros de objetos duplicado na sessão do hibernate, menos rápido que a Query Nativa(SQL), menos legivel em questao de código do que o uso de Criteria, não ter a cláusula UNION do sql, nesse caso teria q criar uma visão no banco de dados, mapear essa visao e fazer um hql em cima dessa visão para obter os resultados de uma UNION.
Criteria: Aos amantes de Criteria nao estou aqui para criticar, Criteria tbm trabalha com objetos e tbm acho mais legivel a nivel de código do que o HQL.
Vantagens: Ser mais legivel a nível de código, possui vários metodos implementados fazendo o papel das cláusulas do sql e do propio HQL.
Desvantagens: Menos rápido numa consulta de banco do que o HQL e a Query Nativa(SQL), alguns metodos não são compatível com alguns BDs, nao possui um metodo com a implementação de union de classes ou tabela, ou seja, irá ter q recorrer ao mapeamento da visao q eu citei acima. E não sei aconteceu só comigu mais algumas consultas mais detalhadas nao retornaram os resultados corretamente, e eu tive q recorrer ao hql e o uso do objeto org.hibernate.classic.Session as vezes ocorrendo o mesmo erro da sessão do hibernate, tendo q recorrer a outras metodos como clear do objeto session para poder inserir ou atualizar algo no bd.
Query Nativa: Use a SQL compativel com o seu bd do jeito q vc quiser e manda através de uma simples conexao JDBC com a ajuda de uma interface PreparedStatement e jah era.
Vantagens: Muito mais rapido que uma HQL e Criteria, vc pode utilizar várias funçoes compativeis com o seu bd q irá interpretar numa boa e bom para que gosta de fazer misérias com sql e deseja aproveitar no java "economizando" assim algumas linhas de código.
Desvantagens: Algumas funções soh funcionam em determinados bancos, se vc usar um convert por exemplo do sql server o firebird nao irá acessar, ai oq vai acontecer??? vc vai rodar.... ou entao vc vai ter q fazer um tratamento no seu código para usar uma sql diferente compativel para cada tipo de banco(Sistema para orgao publico acontece mto isso). Acho q soh esse exemplo basta...hehehehe
Resumindo: odeio Query Nativa, Não muito fã de Criteria e Amante da HQL.
Eh isso ai pessoal quem quiser contribuir eh soh responder...flw ai!
_________________
Att.
Everton Barros
Fil 4:13 "Tudo posso naquele que me fortalece"
daltoncamargo Offline
Posts: 8772
Eu particularmente não sou nada nada fã de usar query nativa para codificação de cosulta em banco, mas em algumas situações, é necessário.
HQL ainda acho que é o melhor caminho, e com certeza em muitos projetos que tenho visto por aí, abrange mais de 80% das consultas.
Criteria? Em alguma situações eu curto usar criteria, mas tudo o que se faz com ela, dá pra se fazer com HQL. Além do mais a idéia que tenho do Criteria, é que é uma tentativa de "enjambre" para os puristas que não curtem ver HQL em seu código.
_________________
Sugestão de Livros
canabrav Offline
Posts: 3
Quanto ao HQL, nunca precisei de UNION, e nunca tive os outros problemas descritos (nunca precisei usar a interface 'classic', e nunca tive problemas de objetos duplicados).
Para não poluir o código java com HQL, eu só uso namedQueries. As queries são declaradas via annotations em suas respectivas entidades, mas todas elas são escritas como constantes em uma classe 'Queries'.
Quanto ao criteria, eu criei um adapter para a session do hibernate com métodos genéricos (que servem pra qualquer entidade) muito úteis, que usam Criteria (findAll(), findByExample(), findByNaturalId()). Mas do ponto de vista geral, prefiro evitar. Principalmente quando os parâmetros de consulta são de várias entidades, acho Criteria quase ilegível.
Quanto ao native query, eu só usaria se estivesse lidando com banco legado, em que há necessidade de chamar stored procedures.
Em relação a desempenho, creio que a única perda do HQL em relação a SQL nativa se refere a converter o HQL em SQL, certo? E ainda não trabalhei em um sistema onde o requisito de desempenho fosse tão grande que a conversão de HQL em SQL fosse problema.
Enfim, minha preferência é por HQL pra consultas específicas (que servem a uma entidade específica), e Criteria pra fazer 'receitas' úteis pra qualquer entidade.
tiago182 Offline
Posts: 17
Não precisa odiar nem amar nada, basta saber oq usar em cada situação
Geralmente uso Criteria p/ queries dinâmicas, acho que se encaixa melhor em situações onde a consulta pode ter N combinações diferentes de acordo com os parâmetros de busca. Além disso a API de Criteria favorece refactoring automáticos através da IDE. Já a HQL cai melhor em queries estáticas e complexas.
_________________
Tiago Fernandez
Blog | Twitter
furutani Offline
Posts: 490
No Criteria ou HQL é possivel usar hints de banco?
Se sim, como isso é feito?
_________________
Até mais,
Roberto Jundi Furutani
Sun Certified Business Component Developer 1.3
Sun Certified Web Component Developer 1.4
Sun Certified Java Programmer 1.4
fknappe Offline
Posts: 1
Concordo com a visão do Tiago.
A única coisa é que particularmente, entre utilizar HQL e uma query nativa, prefiro a query nativa, pois realmente a sintaxe do HQL é meio chatinha.
Mas tudo depende do problema que necessita resolver.
O interesse é saber todas as soluções e não ficar viciada em apenas uma delas.
[ ]'s
_________________
Felipe A. Knappe
Desenvolvedor Java Júnior
daltoncamargo Offline
Posts: 8772
Interessante colocação, pois a refatoração é um ítem bastante interessante e deve ser considerado. Ponto positivo para a Criteria.
_________________
Sugestão de Livros
daltoncamargo Offline
Posts: 8772
Nas suas queries nativas, você popula os objetos manualmente?
_________________
Sugestão de Livros
ronaldtm Offline
Posts: 2299
Criteria: a legibilidade é terrível, mas dá pra fazer algumas coisas interessantes que, ou é chato, ou não dá pra fazer com HQL, como montar queries dinâmicas e reaproveitar condições tanto para o resultado quanto para um count (com projections), coisa que é sempre necessária quando você tem listas paginadas.
HQL: beeeeem mais legível que Criteria (mais legível que SQL, mas não absurdamente), principalmente se for externalizada em um arquivo à parte (XML ou texto), porque indentar queries concatenando strings é uma bosta.
SQL: bom e velho SQL
Obs.: se você usa JPA com Hibernate como provider, grandes são as chances de você não estar escrevendo queries portáveis, porque a especificação da JPAQL é mais limitada que HQL, em detalhes que a gente nem percebe. Por exemplo, o Hibernate permite que você passe coleções como parâmetro (numa cláusula 'in'), mas JPA não. Mas óbvio que, se você estiver usando Hibernate por baixo do JPA, vai funcionar. Só pra deixar claro que essa história de que se você usa JPA você pode trocar o Hibernate por Toplink ou OpenJPA só trocando os JARs é, como dizem, bullshit (a não ser que a sua aplicação é tão bocó que você nunca esbarrou em nenhuma extensão, claro). Portanto, use Hibernate e pronto. Pode usar a API JPA, mas tenha em mente que isso é só uma casca para o Hibernate, e não uma 'camada de independência da tecnologia de persistência', como eu já ouvi várias vezes.
Tetsuo
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
ebarros Offline
Posts: 2342
Soh foi uma colocação, talvez eu tenha me empolgado na expressão..auuhauhauhauha....mas eu jah tive experiencias com as 3 situações das quais citei acima...
_________________
Att.
Everton Barros
Fil 4:13 "Tudo posso naquele que me fortalece"
klausboeing Offline
Posts: 3
Na minha opinião isso é algo muito pessoal, para aqueles que conhecem sql, estão acostumados com a propria estrutura de codificação, parace ser mais interessante trabalhar com HQL, visto que as limitações entre SQL e HQL se restringem a poucas funcionalidades basicamente unions e alguns problemas com coalesce e joins (como forçar um relacionamento left join entre duas tabelas que não possuem um relacionamento).
Aqui na empresa que trabalho usamos muito HQL para relatórios e alguns processos que necessitam de uma busca mais robusta e complexa.
Normalmente não carregamos objetos inteiros, pois isso acaba sendo pouco performatico, sendo que o hibernate gera um sql monstruoso que dependendo do seu ER estora o numero de colunas na clausula SELECT ou FROM, carregamos as colunas que queremos e então usamos um recurso do nosso Framework que popula os VOs.
Isso é muito pratico e produtivo para nós, em mais ou menos 3 minutos tenho uma query montada e retornando uma lista de objetos populados. gosto do HQL por essa maleabilidade com a estruturação da busca dos dados e da manipulação do resultado.
vfpamp Offline
Posts: 6010
Criteria nem em sonho.
Nunca gostei de SQL/HQL por não poder ser compilada. Por várias vezes eu defendi que a HQL deveria ser uma extensão da linguagem Java. Ferramenta que poderia ser montada seguindo a mesma estrutura do AspectJ. Não facilitaria apenas consultas em bancos de dados, mas qualquer iteração sobre uma Collection.
Traduzir uma HQL em SQL é trivial. A parte de carregar VOs da HQL do hibernate é fantastica mas, obviamente, HQL é lenta. É uma pena que as HQLs não sejam implementadas diretamente no banco de dados, retornando streams de VOs ao invés de ResultSets (Nem pense em XML). Imaginem criar uma view com HQL. Será que a Oracle anda brincando com isso? Estou completamente por fora.
Sobre a portabilidade da SQL, não tive problemas com queries SQL ANSI 92. Claro, o set de instruções é reduzido mas você faz tudo que faria num Oracle, com alta performance e portabilidade.
PS: 1992? Pqp! Será que ninguém inventou nada melhor não? Já se foram 16 anos!
PS2: Parabéns pelo nível da discussão galera.
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
vfpamp Offline
Posts: 6010
O que são hints de banco?
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
netstart Offline
Posts: 7
Poderia utilizar-se deste código para fazer o únion:
Claro que você precisaria disparar a execução de duas consultas no banco, para utilizar este método.
Outro código que pode ser utilizado com facilidade na mesma situação
Das duas formas, teremos duas collections, se tornando uma e sem duplicação.
Claro que dependendo da situação seja necessário sobrescrever o equals e o hashCode das entidades
simu Offline
Posts: 8639
(Query) Hints no Oracle são dicas/instruções para o banco, que vão junto com o SQL disfarçados como comentários, por exemplo para indicar qual indice a ser usado.
Exemplo:
O oracle entende que um comentario iniciado com "/*+" é um "hint". Nesse exemplo para usar o os indices t1_abc e t2_abc ao executar esse query.
[]]
_________________
Ganhe um iPad 2 16GB na promoção do Fórum!
Carlos Heuberger
faxineiro do fórum [:-) crie o seu tópico; se for na área errada, pode deixar que eu arrumo! é claro que sobra menos tempo para responder... [:-(
____________________________________________________________________________________________________________
Não respondo MPs com perguntas sobre programação ou sobre Java! Por favor use o fórum!
Sempre execute um printStackTrace dentro do catch "ex.printStackTrace();"
Contra o abuso de IDE's no aprendizado.
This posting is provided AS IS with no warranties and confers no rights.
vfpamp Offline
Posts: 6010
Ahhh, certo! Não sabia que isso eram hints
Da para tentar o Query.setComment, mas acho que não vai funcionar.
Em todo o caso, tah na hora de alguém incluir na SQL esse tipo de comando e remover esse POG da Oracle.
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
ebarros Offline
Posts: 2342
Que eu saiba o hql nao suportar hints.
_________________
Att.
Everton Barros
Fil 4:13 "Tudo posso naquele que me fortalece"
furutani Offline
Posts: 490
Olá
É não encontrei nada que possa inserir os hints corretamente.
Pelo menos no Oracle esses hints ajudam bastante a diminuir os custos de acesso aos dados.
_________________
Até mais,
Roberto Jundi Furutani
Sun Certified Business Component Developer 1.3
Sun Certified Web Component Developer 1.4
Sun Certified Java Programmer 1.4
tiago182 Offline
Posts: 17
Se formos p/ os lados da JPQL, talvez uma abordagem interessante seja o uso de uma DSL interna. Um bom exemplo de implementação é o LIQUidFORM.
_________________
Tiago Fernandez
Blog | Twitter
vfpamp Offline
Posts: 6010
E porque fazer assim:
Se pode ser feito assim? Dá para compilar e tudo :)
Já programaram em PL/SQL? Seria uma coisa daquelas, mas orientada a objetos e criada sobre as java collections.
E dá para fazer muito mais:
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
tiago182 Offline
Posts: 17
@Vitor: Parece uma boa idéia, vc tem um link detalhando como isso funciona? No caso de abrir esse código numa IDE, imagino que seja preciso um plugin p/ conseguir compilar e rodar isso. Sendo assim, vc não acha que partir p/ uma DSL interna seja uma solução mais simples? Valeu!
_________________
Tiago Fernandez
Blog | Twitter
vfpamp Offline
Posts: 6010
O detalhamento é o suporte completo a OQL nativo:http://en.wikipedia.org/wiki/Object_Query_Language
Eu acredito que as alterações na linguagem seriam pequenas, pois é possível desmontar uma instrução select/from/where em um conjunto de instruções padrão do java. A vantagem para o desenvolvedor é um código mais curto, legível e uma ferramenta de query compilada junto com o programa. Com a compilação, a refatoração poderia ser feita também nestas instruções novas.
Sobre as IDEs, da mesma forma que existem plugins para AspectJ, novos plugins poderiam suportar esta nova linguagem.
Claro que eu preferiria que isto fosse adicionado a especificação do Java junto com uma primitiva para o BigInteger e BigDecimal. Mas, como a linguagem não evolui, isso provavelmente não vai acontecer.
Dá uma olhada no post sobre isso no blog do Giovane
Update: Agora que me toquei de uma coisa. O select poderia permitir a VM paralelizar automaticamente o teu código. Exelente para arquiteturas multi-core. Isso seria bombástico.
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
tiago182 Offline
Posts: 17
Muito bom!
Mas como isso tudo não existe (ainda), no final teríamos que nos contentar com APIs do tipo DSL internas como o LiquidForm & afins
@+
_________________
Tiago Fernandez
Blog | Twitter
vfpamp Offline
Posts: 6010
Ou com a HQL mesmo
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Make It Epic
Idéias para projetos em Computação
Como ter boas idéias
Helinton Offline
Posts: 1
Olha eu sou fãn de carterinha do Hibernate, acho ele muinto prático e seguro. Tenho total confiança nele, e utilizo ele em todos sempre que possível, o cod. fica muinto mais civilizado!
ambastos Offline
Posts: 3
Sei que o topico e meio velho, mas tenho o seguinte problema. Uso hqls a bastante tempo e sao muito boas no modo geral, digamos entre 80-90% dos casos, mas o que da raiva e que algumas situacoes ele ingessa. Exemplo: No trabalho tem um Bean "NotaFiscal" o problema e que ele tem varios atributos que sao collections e nesse caso nao da para fazer join fetch com todos eles pois o hibernate gera uma SQL monstruosa e lenta. Percebi que fazendo tres selects separadas e juntando no objeto fica bem mais performatico, porem, ocorre um erro pq ele 'detecta' que as collections estao corrompidas(foram populadas manualmente). Existe uma maneira de fazer com que o hibernate ignore isso em tempo de execucao?
ebarros Offline
Posts: 2342
Cara o ideal seria vc criar um novo tópico, falando sobre o seu problema, a ideia desse tópico e discutir sobre as funcionalidades e desempenho das consultas ao banco e não resolver problemas. Crie um novo tópico.
_________________
Att.
Everton Barros
Fil 4:13 "Tudo posso naquele que me fortalece"
ebarros Offline
Posts: 2342
Aproveitando para ressurgir das cinzas....
Minha opinião eh q isso nao seria viável, pois teria q disparar 2 consultas ao banco eh isso mto mais demorado do que vc criar uma visão e mapea-la, assim vc faria uma consulta em cima da visao, sem precisar disparar duas ou ateh mesmo mais consultas no banco, e em um caso como este onde vc tem q disparar 2 consultas provavelmente vc tem que juntar os objetos do qual vc irá precisar de mais uma lista e ai vai mais um laço, e isso irá consumir mais memória do que o assunto inicial da UNION, ou seja, uma simples visão mapeada resolve, se contar a perfomance(consumo de memória x tempo) e também código mais limpo e enxuto.
_________________
Att.
Everton Barros
Fil 4:13 "Tudo posso naquele que me fortalece"
Relacionados
Problema para montar HQL no Hibernate http://javafree.uol.com.br/topic-875470-Problema-para-montar-HQL-no-Hibernate.html Quão portável é HIBERNATE? http://javafree.uol.com.br/topic-867005-Quao-portavel-e-HIBERNATE.html Dúvida com Hibernate http://javafree.uol.com.br/topic-850606-Duvida-com-Hibernate.html ON: duvidas existenciais. http://javafree.uol.com.br/topic-9945-ON-duvidas-existenciais.html Duvidas sobre hibernate com jta-annotations http://javafree.uol.com.br/topic-863920-Duvidas-sobre-hibernate-com-jtaannotations.html JPA+Hibernate+NativeQuery+MetaData possivel http://javafree.uol.com.br/topic-875326-JPA+Hibernate+NativeQuery+MetaData-possivel.html Hibernate - carregando objetos do banco com e sem lazy http://javafree.uol.com.br/topic-853215-Hibernate-carregando-objetos-do-banco-com-e-sem-lazy.html hibernate->Tradutor de Query http://javafree.uol.com.br/topic-6855-hibernate>Tradutor-de-Query.html Hibernate - Criteria http://javafree.uol.com.br/topic-9194-Hibernate-Criteria.html