Hallo Alfie

Mittlerweile habe ich einige Probleme aufgespürt, die eventuell aus den etwas altertümlichen Tabellendefintionen im Zusammenspiel mit (einigermaßen) aktuellen MySQL-Versionen herrühren.

Kann gut sein. Ich denke, das Problem ist ein grundsätzliches. PHP ist schwach typisiert … Mühsam wird’s im Zusammenspiel mit einer stark typisierten Sprache wie SQL. Das ist vermutlich ein guter Teil der Schnitzeljagd die wir da betreiben.

Zumindest hier spielt das keine Rolle. Die Tabellendefinitionen verzichten an verschiedenen Stellen tatsächlich darauf, einen Default-Wert vorzugeben (Beispiel weiter unten). Das fällt mir bei den Tests immer wieder auf die Füße, weil der MySQL-Server meines Webspaces so eingestellt ist, dass Datensätze, die für Spalten ohne Default-Wert selbst keinen Wert mitbringen, eine Fehlermeldung auslösen und nicht gespeichert werden.

Der Server hat aber wegen seiner Einstellungen auch schon bei der Installation des MLF2-Forums unter projekt-mlf.de hier und da gezickt.

Fehlende Default-Werte für einige Tabellenspalten … Ist dir über die Jahre soetwas schon einmal untergekommen?

In einigen neuen Tabellen (die es bei dir nicht gibt) habe ich immer einen Default vorgegeben. Wenn nicht sinnvoll, immer NULL (auch bei varchar).

Klar, wie du selbst später sagtest, NULL ist NULL. Das gilt natürlich auch für (nicht vorhandene) Zeichenketten.

Wie hat denn deine Tabelle ausgesehen?

CREATE TABLE forum_entries (
  id INT(11) NOT NULL AUTO_INCREMENT,
  pid INT(11) NOT NULL DEFAULT '0',
  tid INT(11) NOT NULL DEFAULT '0',
  uniqid VARCHAR(255) NOT NULL DEFAULT '',
  TIME TIMESTAMP NOT NULL,                  /* hier … */
  last_answer TIMESTAMP NOT NULL,           /* … und hier … */
  edited TIMESTAMP NOT NULL,                /* … und hier */
  edited_by VARCHAR(255) NOT NULL DEFAULT '',
  user_id INT(11) DEFAULT '0',
  name VARCHAR(255) NOT NULL DEFAULT '',
  subject VARCHAR(255) NOT NULL DEFAULT '',
  category INT(11) NOT NULL DEFAULT '0',
  email VARCHAR(255) NOT NULL DEFAULT '',
  hp VARCHAR(255) NOT NULL DEFAULT '',
  place VARCHAR(255) NOT NULL DEFAULT '',
  ip VARCHAR(255) NOT NULL DEFAULT '',
  text text NOT NULL,
  show_signature tinyint(4) DEFAULT '0',
  email_notify tinyint(4) DEFAULT '0',
  marked tinyint(4) DEFAULT '0',
  locked tinyint(4) DEFAULT '0',
  fixed tinyint(4) DEFAULT '0',
  views INT(11) DEFAULT '0',
  PRIMARY KEY (id),
  UNIQUE KEY id (id),
  KEY tid (tid),
  KEY category (category),
  KEY pid (pid),
  KEY fixed (fixed)
);

Bei mir haben last_answer und edited den Default 0000-00-00 00:00:00, NULL ist nicht erlaubt.

Hmm, ein nicht vorhandener Datumswert ist aber auch nur nicht vorhanden. In den Datenbanken bei mir auf Arbeit (MS SQL und MySQL) wird ein solcher „Nichtwert“ konsequent auf NULL gesetzt.

Für die bisher gefundenen Fälle habe ich bei den Zeitstempeln in der Eintrags- und der Benutzerdatentabelle NULL zugelassen und als Default gesetzt …

Musst du dann aber entsprechend in PHP behandeln. Aber was sag ich dir da.

Tatsächlich muss ich das in diesem Kontext nicht. Jedenfalls nicht, um den Datentyp sicherzustellen. Mit den gegenwärtigen Verfahren, einen Querystring zu erzeugen, sind schlussendlich alle Werte Strings. Sicherstellen muss ich nur, dass in der Datenbank die Werte den Spaltentypen entsprechend ankommen und dass die Transportmaskierungen passen.

… sowie in Falle der Spalte "title" in der Smiley-Tabelle den Default-Wert als einen leeren String ('') definiert.

Lustig. Hab ich irgendwann auch so eingerichtet.

Sauberer ist allerdings NULL, als Hotfix geht '' aber durch.

Ich tendiere zudem dazu, so ziemlich alle Spaltendefinitionen mit NOT NULL default '' gegen NULL default NULL zu ersetzen.

Ist sauberer. NULL ist NULL, basta! Ein Leerstring ist Quatsch.

Ebenst.

Tschö, Auge