Data Explorer `int_list` remplace le premier élément par 0

Soutien
1

Je ne sais pas s’il s’agit d’un bug ou si je fais quelque chose de mal, mais il semble que le premier élément d’un tableau int_list soit toujours remplacé par 0 dans une requête de l’explorateur de données.

Par exemple :

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

devient [0, 5, 6].

En examinant :

Si je fais cela dans la console, j’obtiens le résultat attendu :

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

Vous pouvez reproduire le problème avec cette requête :

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

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

Pour provoquer l’erreur (afin de pouvoir la visualiser), supprimez simplement la parenthèse fermante, par exemple :

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

(Regardez le tableau)

2

Il semble que ce qui se produit lorsque vous définissez une valeur par défaut pour un paramètre int_list de cette manière :

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

est que la commande suivante est exécutée :

'"1'.downcase.to_i

Cela renvoie 0.

Vous pouvez contourner le problème en retirant les guillemets de la valeur par défaut du paramètre :

-- int_list :categories = 3, 5, 6

Cette valeur est toujours interprétée comme une chaîne avant d’être divisée en un tableau. Peut-être que le plugin devrait supprimer les guillemets extérieurs s’ils sont ajoutés à une entrée de type chaîne.

3

Merci Simon ! :smiley:

J’étais sûr(e) de l’avoir déjà essayé… et en regardant à nouveau, je vois que modifier les paramètres par défaut dans le corps et cliquer sur save and run n’a aucun effet — soit il faut rafraîchir la page après avoir enregistré, soit modifier également les valeurs dans la case du champ (ce que j’avais totalement oublié).

4

Pour information, je trouve que les paramètres sont vraiment compliqués à analyser. Je me demande si nous ne devrions pas passer à une UX complète plutôt qu’à des commentaires magiques @riking

5

Oui, c’est tout à fait logique de le faire. Les commentaires magiques visaient à optimiser le nombre minimal de migrations de base de données provenant de plugins, ce qui est beaucoup moins problématique de nos jours.