Data Explorer `int_list` sostituisce il primo elemento con 0

Supporto
1

Non sono sicuro se si tratti di un bug o se io stia facendo qualcosa di sbagliato, ma sembra che il primo elemento di un array int_list venga sempre sostituito con 0 in una query dell’esploratore di dati.

Ad esempio:

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

viene trasformato in [0, 5, 6].

Dando un’occhiata a:

Se eseguo la stessa operazione nella console, ottengo l’output previsto:

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

Puoi riprodurre il problema con questa query:

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

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

Per provocare l’errore (così da poterlo visualizzare), basta rimuovere la parentesi chiusa, ad esempio:

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

(Osserva l’array)

2

Sembra che quando si imposta un valore predefinito per un parametro int_list in questo modo:

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

venga eseguito quanto segue:

'"1'.downcase.to_i

Ciò restituirà 0.

È possibile aggirare il problema omettendo le virgolette dal parametro predefinito:

-- int_list :categories = 3, 5, 6

Quel valore viene comunque interpretato come una stringa prima di essere suddiviso in un array. Forse il plugin dovrebbe rimuovere le virgolette esterne se vengono aggiunte a un input di tipo stringa.

3

Grazie Simon! :smiley:

Ero sicuro di averlo già provato… e guardando di nuovo ora vedo che modificare i parametri predefiniti nel corpo e cliccare su salva ed esegui non ha alcun effetto: o devi aggiornare la pagina dopo aver salvato o modificare anche i valori nella casella per il campo (cosa che mi ero completamente dimenticato).

4

Per completezza d’informazione, trovo che i parametri siano davvero complicati da gestire; mi chiedo se dovremmo spostare questa discussione verso un’UX completa rispetto ai commenti magici @riking

5

Sì, ha perfettamente senso farlo: i commenti magici erano ottimizzati per minimizzare il numero di migrazioni del database provenienti dai plugin, che oggi rappresentano un problema molto minore.