xykkong / japi Goto Github PK

A exception acontece aqui.
Temos que implementar o count antes e depois resolver esta questão.

Por algum motivo estranho, o order by não funciona.
Ao entrar nessa URI: /licitacoes/v1/licitacoes?order_by=uasg, no console vemos:

    SELECT modalidade,nome_modalidade,nome_uasg,numero_aviso,uasg FROM dados_abertos.vw_licitacao WHERE 1 = 1 ORDER BY ?, ? OFFSET ? LIMIT 500
    valores ORDER BY: uasg ASC
    valor OFFSET: 0
    nenhum valor no where (considerado 1=1)

Mas, dando f5, o resultado é diferente sempre
(para testar, é preciso estar no banco da prd)

Nesta linha, neste arquivo temos o session.clear(). A intenção disso é limpar as informações do request anterior para o atual não ter problemas. Mas o que acontece é que estamos usando a info do request anterior e limpando depois, fazendo com que o primeiro request seja sempre como se nada tivesse vindo do GET e os próximos funcionam sempre com as informações do anterior, teste só pra ver.

Atualmente, temos na classe abstrata Filter o seguinte código:

    protected Class<? extends Object> valueType = String.class;
    protected List<String> parameters;
    public abstract String getStatement();
    public abstract ArrayList<String> getValues();

Estes métodos abstratos foram feitos na intenção de obrigar o Filter a enviar as informações necessárias para o Service.
Num primeiro momento, em relação ao método getValues(), achei que faria mais sentido nós termos um ArrayList<String> values como parâmetro da classe Filter e retornar o valor dele.

Depois pensei melhor e assumindo que cada filtro (ao ser adicionado na Session) pode se utilizar de vários parâmetros do banco e vários valores vindos da URL, então pensei em criar uma variável do tipo Map<String, List<String>> para isso, substituindo a values e parameters. O que acham?

A ideia aqui é colocar tudo que for discutido e especulado sobre o projeto: frameworks, libs, como implementar tal coisa etc.

Inicialmente começamos com o que tem abaixo:
Itens a serem discutidos:
- parâmetros padrão da URI (offset e order by)
- validação dos campos de cada request
- LinkFactory e Providers (ver a questão de como serão mapeados os Resources)

Colocar o tipo dos dados no service, para podermos associar os Values como dates, por exemplo. Além de facilitar a vida a hora de colocar os filtros no esquema todo.

Ao invés de usar dois vetores, usar um objeto PairParameterValue, por exemplo, e o genericModel ser constituído de um vetor destes pares.
PairParameterValue terá uma String parameter e um Value value.

Criei a issue porque preciso ir embora, se não já tinha consertado isso.