{"id":885,"date":"2011-01-02T14:24:31","date_gmt":"2011-01-02T17:24:31","guid":{"rendered":"https:\/\/devkico.itexto.com.br\/?p=885"},"modified":"2011-01-02T14:34:54","modified_gmt":"2011-01-02T17:34:54","slug":"grails-entendendo-a-busca-por-criterios-criterias","status":"publish","type":"post","link":"https:\/\/devkico.itexto.com.br\/?p=885","title":{"rendered":"Grails: entendendo a busca por crit\u00e9rios (criterias)"},"content":{"rendered":"

\"\"<\/a>Um dos recursos mais mal compreendidos do Grails s\u00e3o as criterias (ser\u00e1 que posso falar “crit\u00e9rias” no plural?). O objetivo deste post \u00e9 ir al\u00e9m do feij\u00e3o com arroz que encontramos na documenta\u00e7\u00e3o oficial. Espero que assim algumas das d\u00favidas mais comuns que escuto a respeito deste recurso sejam resolvidas.<\/p>\n

Vamos tratar de uma situa\u00e7\u00e3o t\u00edpica: uma \u00e1rvore geneal\u00f3gica bem idiota, representada pelas tr\u00eas classes de dom\u00ednio abaixo:<\/p>\n

\r\nclass Pai {\r\n\r\nString nome\r\n\r\nString sobrenome\r\n\r\nstatic hasMany = [filhos:Filho]\r\n\r\nString toString() {this.nome}\r\n\r\n}\r\n\r\nclass Filho {\r\n\r\nString nome\r\n\r\nString sobrenome\r\n\r\nInteger idade\r\n\r\nstatic belongsTo = [pai:Pai]\r\n\r\nstatic hasMany = [filhos:Neto]\r\n\r\nString toString() {this.nome}\r\n\r\n}\r\n\r\nclass Neto {\r\n\r\nString nome\r\n\r\nString sobrenome\r\n\r\nString status\r\n\r\nstatic belongsTo = [pai:Filho]\r\n\r\nString toString() {this.nome}\r\n\r\n}\r\n<\/pre>\n
Com base nesta estrutura de classes, criei uma hierarquia que representei no grafo abaixo, que servir\u00e1 para que possamos trabalhar neste post.<\/p>\n
\"\"<\/a><\/p>\n
T\u00e1: mas o que \u00e9 uma criteria?<\/h2>\n
Grails nos oferece tr\u00eas ferramentas para que possamos fazer consultas em um banco de dados: finders din\u00e2micos, HQL (Hibernate Query Language) e criterias. A busca por crit\u00e9rios do Grails \u00e9 na realidade uma abstra\u00e7\u00e3o do mesmo recurso oferecido pelo Hibernate<\/a>. A diferen\u00e7a \u00e9 que temos aqui uma vers\u00e3o mais “groovy”, uma DSL baseada nos\u00a0builders<\/a> do Groovy.<\/p>\n
Por que usar criterias se j\u00e1 tenho os lindos finders din\u00e2micos?<\/h3>\n
Os finders din\u00e2micos s\u00e3o feitos para consultas simples que envolvam algo entre uma e tr\u00eas condi\u00e7\u00f5es no m\u00e1ximo (minha opini\u00e3o). Se for necess\u00e1rio buscar os registros levando como base o atributo de um atributo composto da sua classe, esque\u00e7a os finders din\u00e2micos. Exerc\u00edcio pra voc\u00ea: retorne usando finders din\u00e2micos todos os netos de “Joe Lonely” em nosso exemplo.<\/p>\n
Por que usar criterias se j\u00e1 tenho HQL?<\/h3>\n
A HQL j\u00e1 nos permite criar consultas BEM mais avan\u00e7adas que os finders din\u00e2micos e com mesmo n\u00edvel de complexidade que as crit\u00e9rias. Al\u00e9m disto, tanto os finders din\u00e2micos quanto as crit\u00e9rias geram, no frigir dos ovos, HQL. Sendo assim, porque usar uma camada superior se posso ir direto ao HQL? Simples: porque a concatena\u00e7\u00e3o de strings uma hora ou outra aparece quando trabalhamos com consultas REALMENTE complexas usando HQL.<\/p>\n
E acredite: concatena\u00e7\u00e3o de strings pode n\u00e3o gerar trag\u00e9dias no primeiro dia, mas quando voc\u00ea menos esperar elas vir\u00e3o atr\u00e1s de voc\u00ea (elas s\u00e3o terr\u00edveis!).<\/p>\n
O B\u00e1sico<\/strong><\/p>\n
Toda classe de dom\u00ednio do Grails possui injetada a fun\u00e7\u00e3o createCriteria<\/em>, que retorna um objeto do tipo grails.gorm.HibernateCriteriaBuilder<\/a>. Esta classe, por sua vez, possui uma fun\u00e7\u00e3o que ser\u00e1 usada em 99% dos casos: a fun\u00e7\u00e3o list<\/em>.<\/p>\n
Na pr\u00e1tica, caso desejemos listar todos os netos do nosso exemplo, poder\u00edamos escrever o c\u00f3digo abaixo:<\/p>\n
\r\n\r\ndef criteria = Neto.createCriteria()\r\ncriteria.list {}\r\n\r\n<\/pre>\n
O m\u00e9todo list sempre recebe como par\u00e2metro uma estrutura hierarquica. Neste caso, como foi passada uma estrutura vazia, todos os resultados s\u00e3o retornados. Caso fosse de nosso interesse retornar todos os netos cujo nome comece com “Pentelho”, escreveriamos o c\u00f3digo abaixo:<\/p>\n
\r\n\r\ndef criteria = Neto.createCriteria()\r\ncriteria.list {\r\nlike("nome", "Pentelho%")\r\n}\r\n\r\n<\/pre>\n
Seriam retornados os netos “Pentelho Lonely Joe” e “Pentelhox Lonely JOe”. No interior desta estrutura incluimos as express\u00f5es que ir\u00e3o compor a nossa consulta.<\/p>\n
Dica:<\/strong> sempre pense na estrutura passada como um documento XML. Assim fica BEM mais f\u00e1cil compreender o que est\u00e1 sendo feito.<\/p>\n
\u00c9 poss\u00edvel tamb\u00e9m usar os operadores l\u00f3gicos or, and e not. No exemplo abaixo listar\u00edamos todos os netos cujo nome comece com “Lori” ou “Pentelho”.<\/p>\n
\r\n\r\ndef criteria = Neto.createCriteria()\r\ncriteria {\r\nor {\r\nlike("nome", "Pentelho%")\r\nlike("nome", "Lori%")\r\n\r\n}\r\n}\r\n\r\n<\/pre>\n
Observe que neste exemplo n\u00e3o usei a fun\u00e7\u00e3o list. Se passarmos diretamente o builder para o objeto criteria, usando a invoca\u00e7\u00e3o din\u00e2mica de m\u00e9todos do Groovy, este j\u00e1 detecta que estamos na realidade chamando list<\/em>. Trata-se apenas de uma conveniencia provida pelo framework.<\/p>\n
A listagem completa de operadores suportados na busca por crit\u00e9rios pode ser obtida neste link: http:\/\/grails.org\/doc\/latest\/ref\/Domain%20Classes\/createCriteria.html<\/a><\/p>\n
Operadores l\u00f3gicos<\/h2>\n
As crit\u00e9rias brilham quando precisamos usar express\u00f5es que envolvam os operadores l\u00f3gicos and<\/strong> e, principalmente, o or<\/strong>. A melhor maneira de expor a sua superioridade \u00e9 expor uma situa\u00e7\u00e3o na qual o uso destes operadores da merda: finders din\u00e2micos.<\/p>\n
Tenha como exemplo a consulta abaixo:<\/p>\n
\r\n\r\nNeto.findAllByNomeLikeOrNomeLikeAndStatus("Pentelho%", "Lori%", "Idiota")\r\n\r\n<\/pre>\n
Que consulta exatamente temos aqui?<\/p>\n