Data Explorer `int_list` ersetzt das erste Element durch 0

Unterstützung
1

Ich bin mir nicht sicher, ob dies ein Fehler ist oder ob ich etwas falsch mache, aber es scheint, als würde das erste Element in einem int_list-Array in einer Data Explorer-Abfrage immer durch 0 ersetzt.

Zum Beispiel:

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

wird zu [0, 5, 6] geändert.

Bei Betrachtung von:

Erhalte ich in der Konsole das erwartete Ergebnis:

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

Sie können dies mit dieser Abfrage reproduzieren:

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

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

Um den Fehler auszulösen (damit Sie den Fehler sehen können), entfernen Sie einfach die schließende Klammer, zum Beispiel:

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

(Schauen Sie sich das Array an)

2

Es sieht so aus, als würde beim Setzen eines Standardwerts für einen int_list-Parameter auf diese Weise:

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

folgendes ausgeführt:

'"1'.downcase.to_i

Das gibt 0 zurück.

Sie können das Problem umgehen, indem Sie die Anführungszeichen beim Standardparameter weglassen:

-- int_list :categories = 3, 5, 6

Dieser Wert wird trotzdem als Zeichenkette interpretiert, bevor er in ein Array aufgeteilt wird. Vielleicht sollte das Plugin äußere Anführungszeichen entfernen, falls sie zu einer Zeichenketteneingabe hinzugefügt werden.

3

Danke, Simon! :smiley:

Ich war mir sicher, dass ich das schon ausprobiert hatte… und beim erneuten Hinsehen stelle ich fest, dass das Ändern der Standardparameter im Body und das Klicken auf Speichern und Ausführen keine Wirkung hat – man muss entweder die Seite nach dem Speichern neu laden oder auch die Werte im Feld für das entsprechende Feld ändern (was ich total vergessen hatte).

4

FWIW finde ich, dass es bei Parametern wirklich schwierig ist, den Überblick zu behalten. Ich frage mich, ob wir das nicht besser auf eine vollständige UX statt auf magische Kommentare verlagern sollten, @riking

5

Ja, das ergibt absolut Sinn. Die magischen Kommentare waren darauf ausgelegt, die Anzahl der von Plugins stammenden Datenbank-Migrationen zu minimieren, was heutzutage weit weniger problematisch ist.