Data Explorer `int_list` reemplaza el primer elemento con 0

Soporte
1

No estoy seguro de si se trata de un error o si estoy haciendo algo mal, pero parece que el primer elemento de un array int_list siempre se reemplaza con 0 en una consulta del explorador de datos.

Por ejemplo:

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

se cambia a [0, 5, 6].

Al observar:

Si lo hago en la consola, obtengo la salida esperada:

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

Puedes reproducirlo con esta consulta:

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

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

Para provocarlo (de modo que puedas ver el error), simplemente elimina el corchete de cierre, por ejemplo:

-- [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   )
                                                         ^

(Mira el array)

2

Parece que lo que sucede cuando estableces un valor predeterminado para un parámetro int_list de esta manera:

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

es que se ejecuta lo siguiente:

'"1'.downcase.to_i

Esto devolverá 0.

Puedes evitar el problema dejando las comillas fuera del parámetro predeterminado:

-- int_list :categories = 3, 5, 6

Ese valor todavía se interpreta como una cadena antes de dividirse en un array. Tal vez el plugin debería eliminar las comillas externas si se agregan a una entrada de tipo cadena.

3

¡Gracias, Simon! :smiley:

Estaba seguro de que lo había probado… y al volver a verlo ahora, veo que cambiar los parámetros predeterminados en el cuerpo y hacer clic en guardar y ejecutar no tiene efecto: o bien debes recargar la página después de guardar, o también cambiar los valores en el cuadro del campo (lo cual se me había olvidado por completo).

4

Por si acaso, encuentro que los parámetros son realmente complicados de razonar. Me pregunto si deberíamos cambiar esto a una UX completa en lugar de comentarios mágicos @riking

5

Sí, tiene todo el sentido hacer eso. Los comentarios mágicos estaban optimizando para minimizar la cantidad de migraciones de bases de datos originadas por plugins, lo cual es mucho menos problemático hoy en día.