derlon wrote: A propósito, eu "ouvi dizer" q 'NamedQueries' "pesam mais" na inicialização da Aplicação: isto é "mito" ou é verdade => alguem poderia esclarecer isto p/ a gente?!

boneazul wrote: Cara pelo que eu li a respeito NamedQueries são mais leves que a api Criteria pois uma vez compiladas elas nunca mais voltam a se repetir diferente da criteria que toda vez é executada e parseada pelo hibernate para se tornar a query nativa do banco que usa,por isso optei por NamedQueries e nao criteria ,não que nao seja facil de mudar no projeto até seria o caso de o cara escolher na aplicação se ele quer criteria ou named query...sei la ...mas não tenho certeza absoluta da abordagem , gosto de usar criteria apenas quando a query é dinamica,exemplo relatorios com filtros ai sim ela é uma forma viavel..mas adoraria ouvir opinioes de outras pessoas a respeito da melhor abordagem..

garcia-jj wrote:

derlon wrote: A propósito, eu "ouvi dizer" q 'NamedQueries' "pesam mais" na inicialização da Aplicação: isto é "mito" ou é verdade => alguem poderia esclarecer isto p/ a gente?!

Não, não são. Obviamente no startup o engine precisa varrer e validar as named-queries e isso tem um custom, porém é algo irrelevante, a menos que você esteja trabalhando com o hardware muito restrito.

boneazul wrote: Cara pelo que eu li a respeito NamedQueries são mais leves que a api Criteria pois uma vez compiladas elas nunca mais voltam a se repetir diferente da criteria que toda vez é executada e parseada pelo hibernate para se tornar a query nativa do banco que usa,por isso optei por NamedQueries e nao criteria ,não que nao seja facil de mudar no projeto até seria o caso de o cara escolher na aplicação se ele quer criteria ou named query...sei la ...mas não tenho certeza absoluta da abordagem , gosto de usar criteria apenas quando a query é dinamica,exemplo relatorios com filtros ai sim ela é uma forma viavel..mas adoraria ouvir opinioes de outras pessoas a respeito da melhor abordagem..

Esse é o motivo de que as named-queries são levemente mais rápidas. Porém como eu disse acima é quase irrelevante exceto quando você tem uma aplicação que possui um milhão de acessos por segundo. Aí cada milésimo de segundo é muito importante.

E concordo com você: as criteria parecem mais OO. Não porque você trabalha com objetos, mas sim porque elas são type-safe, e pelo modo fluente de trabalhar, exemplo:

builder.between(root.get(Debit_.debitDate), lo.getTime(), hi.getTime())

Nesse caso between recebe apenas objetos temporais. Já nas named-queries eu usaria String.

boneazul wrote:coloquei varias outras novidas no gerador (cache com envers,correcao de alguns bugs,etc)

boneazul wrote:e pra semana que vem ja estou estudando de plugar suporte a geração do jboss seam e o jsf ai ja começa a ficar bacana o projeto.....

garcia-jj wrote:

boneazul wrote:coloquei varias outras novidas no gerador (cache com envers,correcao de alguns bugs,etc)

Mas envers é para auditoria, e não cache. Provavelmente você quer dizer ehcache, jboss-cache, etc...

boneazul wrote:e pra semana que vem ja estou estudando de plugar suporte a geração do jboss seam e o jsf ai ja começa a ficar bacana o projeto.....

Você pretende usar SEAM na mesma aplicação que o Vraptor ou a pessoa escolhe um ou outro? Não vejo como usar duas tecnologias que fazem a mesma coisa em um único projeto, a menos que você tenha um legado e esteja fazendo a migração.

renansguima wrote:Pois é tentei acessar e também não consegui :/

fgavioes wrote:kkkkkkkkkkkkk .... A ideia Inicial de nao querer dinheiro de ninguem foii pro saco entao ?/?/