Mysql: Kann keine Null in eine *Zeichenfolge scannen

Der alte Code gab ein leeres []byte für NULL Werte zurück, was es unmöglich machte, einen NULL Wert von einem leeren String zu unterscheiden.
Weitere Informationen finden Sie in Ausgabe #20.

Der Fehler wird vom database/sql Paket aufgrund dieses Ziels zurückgegeben:

* Be flexible with type conversions, but be paranoid about silent
  truncation or other loss of precision.

Sie müssen http://golang.org/pkg/database/sql/#NullString verwenden, wenn die Spalte NULL-Werte enthalten darf

Danke, das macht Sinn.

Ich möchte fast eine Möglichkeit haben, die Bibliothek so zu konfigurieren, dass sie mir das alte Verhalten gibt. In gewisser Weise ist der "Nullwert als Standard" von Go sehr sinnvoll und eliminiert eine Menge Boilerplate-Code. Ich würde das gerne an einer Stelle konfigurierbar platzieren, anstatt es überall in meinem Code zu verstreuen, an dem ich auf eine NULL stoßen könnte. Die Verwendung von NullString usw. ist in Bezug auf den Code ziemlich hässlich.

NULL ist nur ein Albtraum und ich möchte NULLs loswerden. Ich definiere jede Spalte in _my_-Tabellen explizit als NOT NULL, aber gelegentlich enthält ein Befehl wie SHOW PROCESSLIST eine NULL, und mein Code ist einfach egal; Ich möchte stattdessen eine leere Zeichenfolge. Ich werde einfach einen NullString verwenden und seine .Valid-Eigenschaft ignorieren und einfach seinen .String abrufen, der leer ist, wenn die Spalte NULL war.

In der Lage zu sein, dem Treiber mitteilen zu können, dass er NULL für den Typ in einen Nullwert umwandeln soll (oder tatsächlich, ich denke, was er wirklich tun würde, ist das Scannen der Spalte in die Variable zu überspringen) würde eine Menge harter und fehleranfälliger (und nicht- zukunftssicher) Arbeit für mich. Oder, wenn ich nicht den ganzen Boilerplate-Code haben möchte, kann ich mein Risiko eingehen, dass die Spalte a) wirklich nicht nullfähig ist b) für immer so bleibt.

Ich würde es auch vorziehen, dass das Datenbank-/SQL-Paket der "Standard-Nullwert" -Richtlinie von Go folgt. Sie könnten bei Bedarf noch mit den Null*-Typen differenzieren, aber leider wurde die Designentscheidung auf diese Weise getroffen. Vielleicht ändern sie es in Go2 (+1 von mir dafür).
Im Moment habe ich nicht vor, eine Treiberoption dafür hinzuzufügen. Im Vergleich zu PostgreSQL ist das Protokoll bereits ein Durcheinander (obwohl ich annehme, dass es effizienter ist). Ich möchte den Treiber nicht noch mehr durcheinander bringen.
Ein str = nullStr.Value mehr pro gescanntem String ist vorerst das kleinere Übel.

Ich habe versucht, eine Option zu null NULL Werten hinzuzufügen: https://github.com/Go-SQL-Driver/MySQL/tree/zeroNULL
Aber auf Fahrerebene ist das nicht möglich. Wenn Sie den Nullwert auf []byte{} , können Sie ihn auf string und []byte scannen, aber nicht auf numerische Typen. Wenn Sie es auf 0 , können Sie es in numerische Typen scannen, aber Sie erhalten "0" als string / []byte .

Ich verstehe nicht ganz, wie der Treiber tatsächlich scannt, aber statt
setze dest[i] auf etwas, was ist, wenn der Treiber die Einstellung einfach überspringt
dest[i]?

dest ist im Grunde ein []interface{} Slice. Der Standardwert von interface{} ist nil . Die Einstellung dest[i] überspringen hat also das gleiche Ergebnis wie die Einstellung dest[i]=nil

Ich habe die Filiale aktualisiert. Sie können es selbst ausprobieren, wenn Sie möchten.

Das sieht perfekt für meine Bedürfnisse aus und ich werde es das nächste Mal ausprobieren, wenn ich unser aktualisiere
Kopie des Treibers.

Ein anderer Workaround ist mir gerade in den Sinn gekommen:
Verwenden Sie einfach []byte anstelle von string. Das Konvertieren eines nil-[]byte führt zu einer leeren Zeichenfolge:

string([]byte(""))  // => ""
string([]byte(nil)) // => ""

http://play.golang.org/p/nivY1yBK3x

Vielleicht offen halten, vielleicht gut für die Beispiele

Lösung: https://github.com/guregu/null

Da diese Seite immer noch ziemlich weit oben in den Suchergebnissen auftaucht, meine zwei Cent:

Sie können es auch in dem Teil lösen, wo imo eigentlich das Problem liegt: Die Datenbank-Abstraktionsebene. Sie können dieses Problem umgehen, indem Sie die folgenden Schritte ausführen:

  SELECT
    id,
    COALESCE(name, '') as name
  FROM users

Auf diese Weise wird, wenn name NULL enthält, beim Scannen durch eine leere Zeichenfolge ersetzt. Coalesce wird weithin unterstützt.

Ich verstehe nicht, warum hat eine Ausnahme ausgelöst, wenn die Zeichenfolge null ist?

Dieses Beispiel funktioniert für mich

Sie können einen String-Zeiger übergeben, um wie folgt damit umzugehen:

var txt *string
checkErr(result.Scan(&txt))
// do something with type *string

bei mir funktioniert es gut.

Abgesehen von @Dynoms großartigem Kommentar kann es meiner Meinung nach immer noch erwähnenswert sein, dass der Typ sql.NullString praktisch ist, wenn Sie das Problem im Ziel von Scan (was ich als die Go-Seite sehe) angehen möchten der Datenbankabstraktionsebene).

Darüber hinaus behält es die Fähigkeit bei, zwischen einem nil Wert und einem leeren String zu unterscheiden .

Bei nullstring muss der Entwickler eine Karte vo erstellen, wenn die Informationen beispielsweise wie ein Json angezeigt werden sollen. Kein Problem hier, ist ein guter und richtiger Ansatz, aber nicht für alle Fälle sinnvoll, dann kann durch eine Spracheinschränkung eine zusätzliche Arbeit erfolgen.