Wie stellst du booleans in MySQL dar?

[AmicaNoctis]

"PHP machts anders als es eigentlich richtig wäre, und deswegen ist alles scheiße"-Mentalität, die in letzter Zeit hier Einzug hält

Wo hält das Einzug? Und wer sagt, dass PHP Scheiße ist? - Den werd' ich mir mal vorknöpfen! Ernsthaft: ich liebe es, zu PHP zurückzukehren, wenn ich mehrere Tage JS-Klassen coden musste. Und ich liebe diese Knobeleien mit MySQL, mit denen man aus dem doch recht beschränkten Sprachumfang trotzdem die coolsten Abfragen basteln kann. Und ich liebe set('true')-Spalten, die mir so lieblich engegenschreien "Ich bin eine boolean-Spalte, das sieht doch jeder!"

[unset]

Wenn man explode() irgendwas vorwerfen kann, dann dass es keinen dritten Parameter bool $strict hat und bei $strict == true das Type Juggling verhindert.

Und bevor man dann anfängt zu lamentieren, wie sich explode nun verhalten sollte und dass ja eh alles total doof ist, kann man sich auch einfach mal die Zeit nehmen, und das selbst comitten

Das bezieht sich jetzt nicht auf dich sondern auf die generelle "PHP machts anders als es eigentlich richtig wäre, und deswegen ist alles scheiße"-Mentalität, die in letzter Zeit hier Einzug hält

[Quetschi]

Wenn man explode() irgendwas vorwerfen kann, dann dass es keinen dritten Parameter bool $strict hat und bei $strict == true das Type Juggling verhindert.

Wäre eigentlich nicht schlecht, wenn man das Global festlegen könnte. Manchmal ist es ja nett, aber manchmal zwingt es einem halt auch wieder zu gewissen Umwegen.

[onemorenerd]

Wie ich bereits sagte, das ist keine Macke von explode(). Das ist bei allen Funktionen so und es sind nicht die Funktionen, die sich ihre Parameter zurecht-casten. Das macht die Engine.
Im Manual heißt es "a variable's type is determined by the context in which the variable is used" oder "The type of a variable is not usually set by the programmer; rather, it is decided at runtime by PHP depending on the context in which that variable is used."

Wenn man explode() irgendwas vorwerfen kann, dann dass es keinen dritten Parameter bool $strict hat und bei $strict == true das Type Juggling verhindert.

[Quetschi]

Genau das sollte IMHO halt nicht geschehen - wenn explode einen Parameter bekommt, der keinen akzetablen Datentyp enthält, sollte es meinetwegen ein false liefern, aber nicht etwas, was letztenendes doppel- bzw. gar mehrdeutig ist, weil der zurückgelieferte Wert auch einen anderen Ursprung haben könnte.

So errinnert das einen entfernt an die Heisenbergsche Unschärferelation...

[onemorenerd]

Auch das ist nichts besonderes bzw. es liegt nicht an explode. Die Funktion erwartet als zweiten Parameter einen String. Wenn du $emptyString mit NULL belegst, castet PHP das zum String, bevor es die Funktion aufruft. Dass NULL zu einem leeren String gecastet wird, kann man vielleicht als beknackt empfinden - das ist tatsächlich so eine Eigenheit von PHP. Die Entwickler hätten es auch so machen können, dass NULL zu "0" (String mit Zeichen 0) wird oder zu "NULL". Beides wäre aber noch beknackter.

[Quetschi]

Jau - beknackt ist dagegen, dass explode immer noch ein Array, mit einem Element das einen leeren String enthält, zurückgibt, wenn du $emptyString = NULL machst.

[onemorenerd]

Ja sicher gibt es viele Eigenheiten/Spezialitäten in PHP. Aber explode() gehört nicht dazu. Es ist keine Entscheidung der Enwickler von PHP gewesen, dass sich explode() so verhält. Es muss sich so verhalten, denn würde es hierbei

$emptyString = '';
var_dump(explode(',', $emptyString)); 

ein leeres Array zurückgeben, dann müsste es das hierfür auch

$emptyString = '';
var_dump(explode(',', $emptyString.','.$emptyString)); 

und das ginge ja absolut nicht. Dafür müsste man ja in PHP leere Strings verbieten - unmöglich in einer ernst zu nehmenden Sprache.

... muss man sich mal vorstellen, jedes Formularfeld ein Pflichtfeld

[AmicaNoctis]

Edit: set('a','') ist sehr wohl zulässig. Habs grad getestet. Und wenn man einem Datensatz in dieser Spalte '' zuweist, bekommt man das gleiche zurück wie bei der leeren Menge, d.h. man kann es gar nicht unterscheiden. Ziemlich krank!

Kann ich bestätigen. Finde ich auch krank. Ich war mir sicher, dass das nicht zulässig ist.

Was den Vergleich mit explode betrifft: Es würde genauso korrekt arbeiten, wenn es ein leeres Array zurückgeben würde, nur bist du es gewohnt, ein Array mit einem leeren String zu bekommen, so dass du es inzwischen logisch findest. Ein PHP-Anfänger könnte das wieder ganz anders sehen. Für solche Spezialfälle gibt es kein korrekt oder nicht, nur spezifikationskonformes Verhalten oder nicht. Wenn das alles mit Logik entscheidbar wäre, bräuchte man ja keine Doku

PS: Guck dir mal die Spezialfälle für empty() an und sag mir dann mal, ob du das logisch findest oder dich nur dran gewöhnt hast.

[onemorenerd]

Angenommen eine Spalte hat den Typ set('a','b') und ein Datensatz enthält in dieser Spalte die Menge {'a', 'b'}. In PHP bekommt man dann den String "a,b" zurück. Um daraus sowas wie eine Menge zu machen, greift man meist zu explode(',' ...). Alles schick, man erhält ein Array mit zwei Elementen.

Aber hat ein Datensatz nun die leere Menge in dieser Spalte, würde man ein leeres Array erwarten. Doch explode() liefert ein Array mit einem Element, dem leeren String. Imho funktioniert explode() in dieser Hinsicht korrekt.

[onemorenerd]

Edit: set('a','') ist sehr wohl zulässig. Habs grad getestet. Und wenn man einem Datensatz in dieser Spalte '' zuweist, bekommt man das gleiche zurück wie bei der leeren Menge, d.h. man kann es gar nicht unterscheiden. Ziemlich krank!

[AmicaNoctis]

zumal der leere String laut Spaltendefinition kein zugelassenes Element ist.

Der leere String ist nichtmal ein zulässiges Element für eine Spaltendefinition, weil er ja als Repräsentant der leeren Menge verwendet wird

Du kannst keine set('abc', 'de', 'f', '')-Spalte definieren.

[onemorenerd]

0 ist ein int, ein leerer String ist ein String und eine leere Menge ist eine Menge. Damit bin ich völlig einverstanden.
Wenn ich einer Spalte vom Typ set('true') die Einermenge {'true'} zuweise, bekomme ich den String "true" zurück.
Wenn ich der Spalte die leere Menge {} zuweise, bekomme ich einen leeren String zurück.
Das ist imho nicht sehr intuitiv, zumal der leere String laut Spaltendefinition kein zugelassenes Element ist.
Die leere Menge wird durch einen leeren String ausgedrückt.
Anders gehts ja auch nicht. Sie mit NULL auszudrücken widerspräche der dreiwertigen Logik.

Es mag also alles funktionieren, aber intuitiv ist das wirklich nicht und es würde mich auch nicht wundern, wenns gar nicht dem Standard entspricht.

[AmicaNoctis]

Null hat doch damit gar nichts zu tun. Null bedeutet: nicht definierter oder fehlender Wert. Die leere Menge (genau so wie der leere String bei varchar oder die 0 bei int) sind dagegen sehr wohl definierte Werte.

Andere DBMS haben nicht zwangsläufig einen ENUM- oder SET-Typ, da beide nicht zum ANSI SQL 92 Standard gehören. Wenn aber ein SET-Typ vorhanden ist, sollte er genau so funktionieren wie in MySQL, denn alles andere wäre unlogisch. Eine Menge ist nun mal eine Menge und sollte sich auch wie das gleichnamige mathematische Konzept verhalten.

[onemorenerd]

"store any of the values together, from none to all of them" beißt sich mit "feld set('true') not null".
Entspricht das Verhalten von MySQL in dieser Sache eigentlich dem Standard? Handhaben es andere DBMS genauso?