Suporte a filtro de campos data e operadores relacionais.

[emobtech]

Filtro de Data

Para filtrar consultas utilizando campos do tipo data, basta informar os valores dos parâmetros utilizando o padrão ISO-8601 e no fuso UTC. A conversão da data informada para o fuso do servidor é feita automaticamente, antes da consulta ser enviada ao banco de dados.

Exemplos:

• api/v1/usuarios?dataCadastro=2017-11-28T12:40:02.000Z

Operadores Relacionais:

Além do operador relacional =, os filtros agora também suportam os demais operadores, i.e., >, <, >= e <=.

Exemplos:

• api/v1/usuarios?idade=>20
• api/v1/usuarios?idade=>=20
• api/v1/usuarios?idade=<18
• api/v1/usuarios?idade=<=18

É possível combinar esses operadores, a fim de efetuar consultas por intervalo de valores:

• api/v1/usuarios?idade=>18&idade=<21
• api/v1/usuarios?dataCadastro=>=2017-12-20T00:00:00.000Z&dataCadastro=<2017-12-21T00:00:00.000Z

[leonardomerlin]

Opa! Achei massa. Só estranhei um pouco esses operadores, acho que nunca vi algo assim. Normalmente é usado aqueles ge, gte, ... né?! Você usou alguma referência? Manda ai pf.

Outra coisa que fiquei preocupado é se poderia ter algum problema na hora de manipular URL no frontend. Mas isso só será respondido depois dos testes.

De qualquer forma, muito boa a contribuição!

[emobtech]

Não peguei de nenhuma referência. Acredito que seja melhor usar esses operadores, pois eles são mais distinguíveis na hora de identificar, uma vez que "ge", "gt", "le" e "lt" são mais fáceis de confundirem com o valor do parâmetro em si. É a mesma ideia utilizada com o operador do like, *.

Acredito que não, mas se tiver algum problema, nada que um encode simples não resolva na hora de formar o parâmetro.

[reinaldovale]

Você está usando caracteres reservados.

Reserved Characters https://tools.ietf.org/html/rfc3986#page-12

[emobtech]

Posso usar quaisquer caracteres reservados que eu queira depois do igual, contanto que eu os codifique.

[emobtech]

Adicionei também o suporte a datas sem fuso, as quais não serão ajustadas para o fuso do servidor.

Esta alteração é útil quando campos desse tipo ignorarem a informação da hora, como acontece em muitas situações.

Então ao enviar a data sem o Z no final, o qual indica que a presença do fuso UTC, a mesma será utilizada da forma como foi enviada, sem nenhum ajuste de fuso.

Exemplo:

• api/v1/usuarios?dataNascimento=2017-11-28T00:00:00.000

[emobtech]

Gostaria de saber se há uma previsão de uma definição da incorporação ou não desse recurso. Até uma definição, continuaremos usando uma versão customizada aqui no nosso projeto, uma vez que essa funcionalidade é muito necessária ao nosso sistema.

[botelhojp]

@emobtech, marquei a proposta vinculada ao Milestone 3.1.0, previsão para 30/07.

Ainda assim não podemos garantir que a mudança será absorvida, mas com certeza, ela será melhor valiada nas discussões da versão 3.1.0

Como envolve uma classe crítica do módulo CRUD, precisamos reforçar os testes. Se você tiver testes unitários nos ajudará.

[emobtech]

@botelhojp Obrigado pela resposta. Infelizmente não tenho nenhum teste unitário para essa funcionalidade, mas já foi bastante testado aqui pelo nosso lado, uma vez que vem sendo usada em algumas funcionalidades do nosso sistema. Vamos ficar no aguardo então. Qualquer dúvida, pode chamar #85 3756.

[emobtech]

E ai, pessoal. Alguma nova previsão? Estou esperando um posicionamento de vocês se vão aceitar isso ou não, pois o nosso sistema aqui faz uso dessas melhorias, e por causa disso ainda não usamos a última versão do framework. Caso queiram conversar melhor, me chamem no ramal 85-3756 (Ernandes).

[emersonfaria]

Ernandes, conforme conversa telefônica que tivemos a pouco, vou dar um encaminhamento para esse assunto.

Adianto que será necessário ter os testes automatizados para cada caminho feliz e para cada tratamento de exceção. Peço que adicione esses testes em sua implementação.

[emobtech]

Adicionei o suporte a ordenação de campos de segundo nível.

Por exemplo: /api/usuarios/sort=perfil(nome)