Data Explorer `int_list` substitui o 1º elemento por 0

Suporte
1

Não tenho certeza se isso é um bug ou se estou fazendo algo errado, mas parece que o primeiro elemento de um array int_list é sempre substituído por 0 em uma consulta do Data Explorer.

Exemplo:

-- int_list :categories = "3, 5, 6"

é alterado para [0, 5, 6]

Olhando em:

Se eu fizer isso no console, obtenho a saída esperada:

string = "3,5,6"
value = string.split(',').map { |s| s.downcase == '#null' ? nil : s.to_i }
=> [3, 5, 6]

Você pode reproduzir com esta consulta:

-- [params]
-- int_list :categories = "3, 5, 6"

SELECT *
FROM topics 
WHERE topics.category_id = ANY (ARRAY [ :categories ]  )

Para quebrá-la (para que você possa ver o erro), basta remover o colchete de fechamento, por exemplo:

-- [params]
-- int_list :categories = "3, 5, 6"

SELECT *
FROM topics 
WHERE topics.category_id = ANY (ARRAY [ :categories   )

PG::SyntaxError: ERROR:  syntax error at or near ")"
LINE 12: WHERE topics.category_id = ANY (ARRAY [ 0,5,6   )
                                                         ^

(Olhe para o array)

2

Parece que o que acontece quando você define um valor padrão para um parâmetro int_list dessa maneira:

-- int_list :categories = "3, 5, 6"

é que o seguinte é executado:

'"1'.downcase.to_i

Isso retornará 0.

Você pode contornar o problema removendo as aspas do parâmetro padrão:

-- int_list :categories = 3, 5, 6

Esse valor ainda é interpretado como uma string antes de ser dividido em um array. Talvez o plugin devesse remover as aspas externas se elas forem adicionadas a uma entrada do tipo string.

3

Obrigado, Simon! :smiley:

Eu tinha certeza de que já tinha tentado isso… e olhando novamente agora, vejo que alterar os parâmetros padrão no corpo e clicar em salvar e executar não tem efeito - você precisa ou atualizar a página após salvar ou alterar os valores na caixa do campo também (o que eu tinha totalmente esquecido).

4

Para o que vale, acho que os parâmetros são realmente complicados de analisar. Estou me perguntando se devemos mudar isso para UX completa versus comentários mágicos @riking

5

Sim, faz todo o sentido fazer isso. Os comentários mágicos estavam otimizando para o menor número de migrações de banco de dados originadas de plugins, o que é muito menos problemático hoje em dia.