Bug eclipselink case when

Olá,

Alguém já viu esse bug? -> http://www.eclipse.org/forums/index.php/t/357371/

É exatamente igual ao que estou passando aqui, estou até pensando em trocar a lib para algum outro framework JPA2… Alguém sabe se tem solução (sem deixar de usar o CriteriaBuilder)?

Se não conhecerem, qual framework JPA2 vcs trabalham e quais as vantagens dele?

uff, estou pensando em desistir do eclipselink mesmo, alguém sabe se hibernate ou toplink não tem esse bug? Quem usa aí, qual o nível de bugs deles?

Baixei o source e recompilei o eclipselink, mas “o buraco é mais embaixo”, teria que mudar (creio eu, porque na CriteriaBuilderImpl, que parecia ter o erro, na verdade parece que nem é chamado…) muita coisa para talvez funcionar, não compensa ter que fazer o teste na api inteira…

Quais implementações do JPA2 vcs usam e quais as vantagens e desvantagens que consideram?

Sempre utilizei o Hibernate.

No no tópico do bug diz que você pode usar JPQL como solução alternativa. [=

estou fazendo a conversão para hibernate mesmo, felizmente tem o hibernate jpa ^^, não tem que mudar muita coisa!

Sim, dá para usar JPQL, mas aí perderia a vantagem de usar criteria para montar consultas dinâmicas, que é ter um código legível. Estou trocando porque já é a segunda coisa que o EclipseLink me deixa “na mão”… A primeira foi usar JPQL com subquery no from (não sei se HQL deixa), que tive que usar criteriabuilder para montar uma consulta estática… Agora que quero uma consulta dinâmica, não quero ser também obrigado a usar algo “não para isso”… Concatenar strings para montar um JPQL não vai ficar legal no código.

Sobre o Hibernate, quais as vantagens que você considera?

Obs: fazendo testes com o hibernate no projeto agora, por enquanto nenhum bug no funcionamento, nem onde eu achei que poderia dar LazyInitializationException deu (ainda…)

Depois que terminar de testar, vou começar a configurar cache, e falando nisso, qual a diferença entre o ehcache e o infinispan para second level cache? Qual a vantagem de cada?

esqueci de mencionar, sem o cache (mas o eclipselink com cache), estou achando o eclipselink mais rápido. Mas ainda não testei bem nem fiz tuning do hibernate.

Agora tenho que ver como configurar first level cache e second level cache…

É cara, só trabalhei com Hibernate até hoje. Não sei te falar. [=

Sobre cache vou deixar outra pessoa responder! [=

sim, mas somente considerando o hibernate, o que vc considera bom nele e o que considera deficiente?

Fazendo uns testes aqui… Com o log no full (como também fazia no eclipselink) ele consome muito mais permgen que o eclipselink… Mesmo o eclipselink com cache e ele sem… (estava usando hard_weak no eclipselink)

Nada relacionado a grande escala como o que parece que você está mexendo.

Amo o criteria deles mas não tem como utilizar sem ser pelo Session do Hibernate. =/

ouvi falar muito bem do criteria dele, ouvi dizer que é muito melhor que o criteria do JPA. Será que eu consigo usar o criteria dele para ver como é, injetando um Session em um EJB, mas utilizando persistence.xml como no JPA? (para eu não ter que trocar o que já está em JPA 2)

Chegou a encontrar algum bug no hibernate? (só para eu ter uma noção se vou ver muito isso pela frente ou não…)

Como disse, nunca vi como utilizar criteria do hibernate utilizando transação do JPA. E o EJB só injeta (até onde eu sei) transação do JPA.

Cara, eu sei que a versão 4 do hibernate tá dando uns bugs mas quanto a multitenacy. nada mais.

uff, não tenho sorte nenhuma mesmo viu… HQL (montado pelo criteriaBuilder) com bug também…

Esse bug: http://stackoverflow.com/questions/8468682/hibernate-hql-use-case-when-in-count-statement-like-if-in-mysql

Tenso, vou voltar para EclipseLink porque ele é mais leve (tanto para memória quanto para processamento) e tinha resposta mais rápida.

Obs: estava fazendo os testes, ambos com as mesmas configs de cache, e o eclipselink estava cerca de 30% mais rápido que o Hibernate… Qualquer hora faço um benchmark mais científico…

Tenso, vou voltar para eclipselink e montar essa query dinâmica concatenando strings com StringBuilder T.T (o que eu não queria fazer desde o começo…)