Só o fato de não ter criteria e saveOrUpdate() mostram como JPA é um fiasco completo.
JPA fica bom quando usado com a implementação do Hibernate e usado os JPATemplate do Spring
Daí sim fica bom (mesmo!)
Concordo em não ter criteria… algo mais inutil que ja vi é este criteria… para querys pequenas até vai mas vai pegar um relatorio filho da p**** pra fazer com uma porrada de campos e de tabelas e vai querer usar criteria pra fazer isto… não é nada trivial… vc vai se quebrar muito pra fazer isto em criteria… algo que vc tera uma dor de cabeça muito menor se fizer em hql com stringbuilders ou com bem menas dor de cabeça se fizer em sql nativo mesmo… ao meu ver coisas do tipo hql são uteis para pequenas consultas… este tipo de coisa não é muito bom pois vamos que o cliente ou o analista de negocios me peça a query da app para analisar? com criteria ou hql eu terei que refazer o sql nativo para mandar para ele pois o qual o hibernate gera é quase que ilegivel… e poucos teriam coragem de mandar algo daquele jeito… e se vc quiser testar em seu sgdb? mesma coisa… vc não vai ter como depurar o hql ou o criteria no seu sgdb… porem com sql nativo não tera problemas… alem disso hql e criteria tem uma curva de aprendizado longa… e no final toda aquela tranqueira de codigo vai virar sql nativo para ser executado… e quem vai fazer isto para vc? o framework… quem lhe garante que ele ira fazer da melhor forma? ja vi varios problemas de relatorios lentos por causa desses criterias e hqls da vida… acho que criteria e hql são bem vindos para coisas pequenas porem relatorios grandes eles só são uma dor de cabeça… agora criteria é algo totalmente fresco… montar querys via codigo pq não acha bonito colocar hqls ou sqls no codigo… o que isto acrescenta em desempenho, legibilidade, e em facil manutenção? acho que nada… alem do mais se analisar em questão de performace o framework tera que parsear sua query de acordo com seu criteria e isto ja é perca de performace…
acho que muitos pensão que ao usar um framework devem usar 100% dele e não o 100% dele que é devidamente util em seu projeto…
Companheiro, criteria e HQL não existem para serem utilizadas pra fazer relatórios, se alguém lhe disse que deveria usar isso pra relatórios, avise ao seu companheiro que a proposta delas não é essa.
HQL e criteria são para montar consultas complexas entre objetos e não entre tabelas.
Outra coisa, por favor, use parágrafos, pontos finais e vírgulas no seu texto, ele é praticamente ininteligível.
[quote=luistiagos]Concordo em não ter criteria… algo mais inutil que ja vi é este criteria… para querys pequenas até vai mas vai pegar um relatorio filho da p**** pra fazer com uma porrada de campos e de tabelas e vai querer usar criteria pra fazer isto… não é nada trivial… vc vai se quebrar muito pra fazer isto em criteria… algo que vc tera uma dor de cabeça muito menor se fizer em hql com stringbuilders ou com bem menas dor de cabeça se fizer em sql nativo mesmo… ao meu ver coisas do tipo hql são uteis para pequenas consultas… este tipo de coisa não é muito bom pois vamos que o cliente ou o analista de negocios me peça a query da app para analisar? com criteria ou hql eu terei que refazer o sql nativo para mandar para ele pois o qual o hibernate gera é quase que ilegivel… e poucos teriam coragem de mandar algo daquele jeito… e se vc quiser testar em seu sgdb? mesma coisa… vc não vai ter como depurar o hql ou o criteria no seu sgdb… porem com sql nativo não tera problemas… alem disso hql e criteria tem uma curva de aprendizado longa… e no final toda aquela tranqueira de codigo vai virar sql nativo para ser executado… e quem vai fazer isto para vc? o framework… quem lhe garante que ele ira fazer da melhor forma? ja vi varios problemas de relatorios lentos por causa desses criterias e hqls da vida… acho que criteria e hql são bem vindos para coisas pequenas porem relatorios grandes eles só são uma dor de cabeça… agora criteria é algo totalmente fresco… montar querys via codigo pq não acha bonito colocar hqls ou sqls no codigo… o que isto acrescenta em desempenho, legibilidade, e em facil manutenção? acho que nada… alem do mais se analisar em questão de performace o framework tera que parsear sua query de acordo com seu criteria e isto ja é perca de performace…
acho que muitos pensão que ao usar um framework devem usar 100% dele e não o 100% dele que é devidamente util em seu projeto… [/quote]
Criteria é necessário para ORM, relatórios são basicamente sínteses de dados tabulados, você nunca deve usar uma ferramenta de ORM para gerar relatórios. se voce vai montar relatórios com HQL é algo totalmente estúpido.
Além do que relatório em tese você desenha em uma ferramenta como Crystal ou IReport, para que você usaria um ORM para isso?
[quote=Mauricio Linhares]Companheiro, criteria e HQL não existem para serem utilizadas pra fazer relatórios, se alguém lhe disse que deveria usar isso pra relatórios, avise ao seu companheiro que a proposta delas não é essa.
HQL e criteria são para montar consultas complexas entre objetos e não entre tabelas.
Outra coisa, por favor, use parágrafos, pontos finais e vírgulas no seu texto, ele é praticamente ininteligível.[/quote]
Lembrei dessa thread porque rolou discussão no CEJUG sobre um problema entre implementações da JPA. Ainda continuamos sem uma spec adequada de ORM, a JCP teimou com JDO durante tempos, agora está teimando com JPA sem Criteria 
Mas o que me espanta é que ainda não sabem para que é HQL, Criteria… enfim, ORM!
Já faz tempo que eu desisti de esperar qualquer coisa decente do JCP, é muita politicagem num buraco só. Por isso que Java nunca vai ter nada comparável a LINQ, eles nunca vão conseguir convencer todos os vendors a implementar aquilo completo (assim como eles não conseguiram nem convencer eles a ter as suas próprias APIs de criteria).
Democracia não funciona nesses casos, ainda mais uma onde tanta gente pode meter o bedelho. O negócio é ignorar que isso existe e simplesmente continuar a utilizar o Hibernate.
Pegando o Early Draft Review da JSR 317, você vê na página 101 o seguinte trecho:
Portanto, calma. Ainda há uma chance das Criterias aparecerem.
[quote=Mauricio Linhares]Já faz tempo que eu desisti de esperar qualquer coisa decente do JCP, é muita politicagem num buraco só. Por isso que Java nunca vai ter nada comparável a LINQ, eles nunca vão conseguir convencer todos os vendors a implementar aquilo completo (assim como eles não conseguiram nem convencer eles a ter as suas próprias APIs de criteria).
Democracia não funciona nesses casos, ainda mais uma onde tanta gente pode meter o bedelho. O negócio é ignorar que isso existe e simplesmente continuar a utilizar o Hibernate.[/quote]
Acabei de escrever no blog sobre a Thread no CEJUG -> http://www.milfont.org/tech/2008/10/27/especificacao-ou-implementacao/
Problema é que não dá para simplesmente ignorar, porque a força de uma especificação tem muito peso nas decisões, o risco de sair da especificação é o que deixou a comunidade java tão presa [presa fácil] ao EJB2.
Se foi tão difícil convencer que aquilo era uma desgraça, imagina dizer hoje que ignorem EJB e JPA e continuem utilizando Spring e Hibernate!
A força de seguir a manada para muitos ainda é mais forte do que sustentar o melhor.
[quote=Leonardo3001]Pegando o Early Draft Review da JSR 317, você vê na página 101 o seguinte trecho:
Portanto, calma. Ainda há uma chance das Criterias aparecerem.
[/quote]
Estão trabalhando por 2 anos na spec e não saiu nessa Draft, acho muito improvável que saia na próxima.
Eu não consigo ver vantagem nenhuma em usar JPA, só desvantagens, não entendo com as pessoas podem continuar a usar isso e ainda achar que é bom.
Eu também não, o trabalho é convencer a manada a favor disso. Quantos projetos eu vejo o pessoal evitando usar Criteria para não ficar preso a implementação e se matando de Queries, ainda mais de NamedQuery via anotação
eu uso e abuso de consultas OO.
enquanto JPA não tiver, nem penso em adotar.
gostaria de ver esse DAO concatenando strings:[code] public List<Pessoa> findAllByCpfCnpj(String param) {
if (param==null)
param = “”;
else
param = param.replaceAll("[^0-9]",""); // elimina caracters dif. de numeros
if (param.equals(""))
return getHibernateTemplate().find(“from Pessoa order by cpfCnpj”);
Long exato = Long.parseLong(param); // exemplo: "143"
Criterion restri = Restrictions.eq(“cpfCnpj”, exato);
int tam = param.length();
String acresc = “0”;
while (acresc.length()+tam<=13) {
Long de = Long.parseLong(param+acresc); // exemplo: "1430000"
Long ate = Long.parseLong(param+acresc.replace(‘0’, ‘9’)); // exemplo: "1439999"
restri = Restrictions.or(restri, Restrictions.between(“cpfCnpj”, de, ate));
acresc = acresc+“0”;
}
Long de = Long.parseLong(param+acresc);
restri = Restrictions.or(restri,
Restrictions.between(“cpfCnpj”, de, Long.MAX_VALUE));
DetachedCriteria cri = DetachedCriteria.forClass(Pessoa.class)
.add(restri).addOrder(Order.asc(“cpfCnpj”));
return getHibernateTemplate().findByCriteria(cri);
}[/code]ficaria abusardamente sujo.[quote=ricardosoares]eu uso e abuso de consultas OO.
enquanto JPA não tiver, nem penso em adotar.
gostaria de ver esse DAO concatenando strings:[code] public List<Pessoa> findAllByCpfCnpj(String param) {
if (param==null)
param = “”;
else
param = param.replaceAll("[^0-9]",""); // elimina caracters dif. de numeros
if (param.equals(""))
return getHibernateTemplate().find(“from Pessoa order by cpfCnpj”);
Long exato = Long.parseLong(param); // exemplo: "143"
Criterion restri = Restrictions.eq(“cpfCnpj”, exato);
int tam = param.length();
String acresc = “0”;
while (acresc.length()+tam<=13) {
Long de = Long.parseLong(param+acresc); // exemplo: "1430000"
Long ate = Long.parseLong(param+acresc.replace(‘0’, ‘9’)); // exemplo: "1439999"
restri = Restrictions.or(restri, Restrictions.between(“cpfCnpj”, de, ate));
acresc = acresc+“0”;
}
Long de = Long.parseLong(param+acresc);
restri = Restrictions.or(restri,
Restrictions.between(“cpfCnpj”, de, Long.MAX_VALUE));
DetachedCriteria cri = DetachedCriteria.forClass(Pessoa.class)
.add(restri).addOrder(Order.asc(“cpfCnpj”));
return getHibernateTemplate().findByCriteria(cri);
}[/code]ficaria abusardamente sujo.[/quote]
Ricardo, deixa eu te contar um segredo: ele já está absurdamente sujo 
[quote=Leonardo3001]Pegando o Early Draft Review da JSR 317, você vê na página 101 o seguinte trecho:
Portanto, calma. Ainda há uma chance das Criterias aparecerem.
[/quote]
Vao aparecer, ja confirmaram!
[quote=plentz]
Ricardo, deixa eu te contar um segredo: ele já está absurdamente sujo :)[/quote]
Tá aí uma coisa que não é segredo pra ninguém: q o código está sujo.
O que continua um segredo é: conseguir o mesmo resultado numa programação mais limpa.
Me ajuda a desvendar :?:
Desculpe reativar o tópico, mas é que já foi lançado o Public Draft Review do JPA 2.0, onde foi acrescentada a nova API de Criteria.
De acordo com a nova API, aquele exemplo acima (de buscar pessoas pelos primeiros dígitos do CPF/CNPJ) não ficaria tão feio assim. Veja:
public List<Pessoa> findAllByCpfCnpj(String param) {
if (param == null) {
param = "";
} else {
param = param.replaceAll("[^0-9]", ""); // elimina caracters dif. de numeros
}
QueryBuilder queryBuilder = em.getQueryBuilder();
DomainObject pessoa = queryBuilder.createQueryDefinition(Pessoa.class);
QueryDefinition qdef = pessoa.where(pessoa.get("cpfCnpj").like(param + "%"));
Query q = em.createQuery(qdef);
return q.getResultList();
}E aí, o que acharam?
Desculpa a todos por está ressuscitando o topico.
Gostaria de dizer que JPA pra mim ainda tem que crescer muito, já utilizei ele em muitos projetos, mas… o Hibernate 4.0 e suas melhorias etc veio pra ficar, vale a pena sim investir no Hibernate, acredito que o JPA tem ainda sim uma longa estrada pela frente.
Abraços :roll: .
cara não sei mesmo do que vocês reclama 
pois mergulhei no JPA e não sei nada de Hibernate e JDBC
mas acho ela muito fera
se conhecesse os outros também reclamaria :twisted:
8)
Como o RafaelRio citou, existem maneiras alternativas. Ainda, acho muito purismo usar Criteria se você resolve seu problema de outras formas.
Agora, se na tua aplicação você muda além de parâmetros condicionais, trechos da própria sentença, na minha opinião seu método tá muito “gordo”.
"Ah, então vou repetir a Query inteira se quiser acrescentar um GROUP BY ou HAVING diferente para cada caso?"
Bem eu acho no mínimo estranho o cara usar lógica para montar a Query de modo elegante. Cada query no seu lugar, chamada através de, quase sempre, um método que corresponde à sua ação especificamente. Ou talvez verificar se um único método deve ser tão responsável assim.
Na minha opinião criar uma extensão para a API só para evitar concatenações é forçar a barra demais.
[]s amigos!