MySQL 4.1 > 5.0 Migration

Hallo,

ich habe auf MySQL 4.1 mit Unicode eine Anwendung entwickelt und will
die nun für jemanden bei 1&1 installieren. Die haben aber leider nur
eine 4.0.* und eine 5er Version. Bei 4.0 funktioniert Unicode nicht
richtig und bei 5.0 gibt es nur Probleme, mein MD5 Passwort System
funktioniert z.B. nicht mehr, obwohl ich die Passwörter mit phpMyAdmin
neu geschrieben habe. Und dann gibt es ständig Fehler bei simplen JOINs,
die auf 3.23 und 4.1 noch funktioniert haben.

Was muß ich alles beachten? Die Tipps aus der MySQL 5 Doku bin ich schon
durch, bringt aber keine Besserung.

Gruß,
Oliver

Re: MySQL 4.1 > 5.0 Migration

"Oliver Benning" wrote:

> ... bei 5.0 gibt es nur Probleme, mein MD5 Passwort System
> funktioniert z.B. nicht mehr, obwohl ich die Passwörter mit phpMyAdmin
> neu geschrieben habe.

Details? Ein MD5-Hash ist ein MD5-Hash ist ein MD5-Hash. Egal was für
eine MySQL-Version das ist. Speicherst du den auch hypsch in einem
BINARY() Feld? Oder verwendest wenigstens die BINARY Collation?

> Und dann gibt es ständig Fehler bei simplen JOINs,
> die auf 3.23 und 4.1 noch funktioniert haben.

Ja. Du sollst ","-Joins und JOIN-Joins nicht mischen.

> Was muß ich alles beachten? Die Tipps aus der MySQL 5 Doku bin ich schon
> durch, bringt aber keine Besserung.

Wenn du wirklich alle Punkte durch hast, die das Manual für die 4.1 ->
5.0 Migration enthält, solltest du _konkrete_ Probleme hier posten.

Evtl. schaust du vorher mal bei vorbei, ob das ein
bekanntes Problem ist (wie bei den JOINs - eigentlich sollte das gefixt
sein, aber vielleicht hat 1&1 ja noch eine ältere Version).


XL

Re: MySQL 4.1 > 5.0 Migration

Axel Schwenke wrote:

> Details? Ein MD5-Hash ist ein MD5-Hash ist ein MD5-Hash. Egal was für
> eine MySQL-Version das ist. Speicherst du den auch hypsch in einem
> BINARY() Feld? Oder verwendest wenigstens die BINARY Collation?

Vielleicht habe ich was übersehen, aber wozu wäre das denn nötig? Die MD
()-Funktion von MySQL spuckt den Hash als Hex-String aus:


> select md5('!');
+----------------------------------+
| md5('!') |
+----------------------------------+
| 9033e0e305f247c0c3c80d0c7848c8b3 |
+----------------------------------+
1 row in set (0,01 sec)

und selbst wenn - warum auch immer - auf anderem Wege ein md5-Wert in die
Datenbank wandern sollte, der mit Großbuchstaben arbeitet, sollten die
doch als gleich erachtet werden. Dann wäre binary doch gerade
kontraproduktiv.

Was übersehe ich?


Thomas
--
Manche theoretischen Informatiker glauben ja, daß Computer mit Rauch
funktionieren, denn wenn der Rauch entweicht, dann funktionieren sie
nicht mehr :-). (Peter Heckert in dcoulm)

Re: MySQL 4.1 > 5.0 Migration

Thomas Rachel wrote:
> Axel Schwenke wrote:
>
>> Details? Ein MD5-Hash ist ein MD5-Hash ist ein MD5-Hash. Egal was für
>> eine MySQL-Version das ist. Speicherst du den auch hypsch in einem
>> BINARY() Feld? Oder verwendest wenigstens die BINARY Collation?
>
> Vielleicht habe ich was übersehen, aber wozu wäre das denn nötig?

Nicht "nötig" im Sinne von "es geht nicht anders", eher im Sinne von
wünschenswert. Schließlich sind es binäre Daten, da will man auch binär
vergleichen.

> wenn - warum auch immer - auf anderem Wege ein md5-Wert in die
> Datenbank wandern sollte, der mit Großbuchstaben arbeitet, sollten die
> doch als gleich erachtet werden. Dann wäre binary doch gerade
> kontraproduktiv.

Man sollte sich natürlich vorher für upper *oder* lower case
entscheiden - sinnvoll wäre lower case, weil es das ist was die
eingebaute Funktion liefert.

Notfalls muß man halt noch ein LOWER() um die zu vergleichenden
Werte wickeln. Ideal wäre ein 'hexadecimal' Zeichensatz, der nur
[0-9a-fA-F] erlaubt und case-insensitiv vergleicht.
Gibts leider nicht :-|


XL

Re: MySQL 4.1 > 5.0 Migration

Axel Schwenke wrote:


> Nicht "nötig" im Sinne von "es geht nicht anders", eher im Sinne von
> wünschenswert. Schließlich sind es binäre Daten, da will man auch binär
> vergleichen.

Recht hättest Du IMHO, wenn man mittels UNHEX() oder sonstwie die Daten
tatsächlich binär speichern wollte (etwa zwecks Speicherplatzersparnis)
- dann wäre eine binäre Speicherung zwingend erforderlich.

Aber gerade bei Hexdaten würde ich nicht mehr von binär reden.
Schließlich gilt da ja explizit 'EB' == 'eb', von daher wäre IMHO einer
case-insensitive Sortierung der Vorzug zu geben.

> Notfalls muß man halt noch ein LOWER() um die zu vergleichenden
> Werte wickeln. Ideal wäre ein 'hexadecimal' Zeichensatz, der nur
> [0-9a-fA-F] erlaubt und case-insensitiv vergleicht.
> Gibts leider nicht :-|

Eben - und eine case-insensitive Irgendwas-Sortierung ist daher noch
näher am Gewünschten dran als eine case-sensitive Sortierung.

YMMV.


Thomas
--
Ich hätte gerne 5 neue Newsgruppen. Zwei davon wären ganz eilig, da
Geburtstagsgeschenke. Bitte um Benachrichtigung, damit ich nach
Einrichtung über den Namen befinden werde.
in de.alt.admin

Re: MySQL 4.1 > 5.0 Migration

Axel Schwenke wrote:
> "Oliver Benning" wrote:
>
>> ... bei 5.0 gibt es nur Probleme, mein MD5 Passwort System
>> funktioniert z.B. nicht mehr, obwohl ich die Passwörter mit
>> phpMyAdmin neu geschrieben habe.
>
> Details? Ein MD5-Hash ist ein MD5-Hash ist ein MD5-Hash. Egal was für
> eine MySQL-Version das ist. Speicherst du den auch hypsch in einem
> BINARY() Feld? Oder verwendest wenigstens die BINARY Collation?
>
>> Was muß ich alles beachten? Die Tipps aus der MySQL 5 Doku bin ich
>> schon durch, bringt aber keine Besserung.
>
> Wenn du wirklich alle Punkte durch hast, die das Manual für die 4.1 ->
> 5.0 Migration enthält, solltest du _konkrete_ Probleme hier posten.

Ich habe folgende Nested-Sets Abfrage, die schon immer in 3.23 und
zuletzt in 4.1 funktioniert hat.

SELECT
t1.*, round((t1.menu_rgt - t1.menu_lft-1) / 2,0) AS menu_childs,
count(*) + (t1.menu_lft > 1) AS menu_level, ((min(t2.menu_rgt) -
t1.menu_rgt - (t1.menu_lft > 1)) / 2) > 0 AS menu_lower,
(( (t1.menu_lft - max(t2.menu_lft) > 1) )) AS menu_upper
FROM
menu AS t1,
menu AS t2
LEFT JOIN menu_names AS t3
ON (t1.menu_id = t3.mnam_menu_id)
WHERE
t1.menu_lft BETWEEN t2.menu_lft AND t2.menu_rgt AND
(t2.menu_root_id = t1.menu_root_id) AND
(t2.menu_id != t1.menu_id OR t1.menu_lft = 1) AND
t3.mnam_lang_id = 1
GROUP BY
t1.menu_root_id, t1.menu_id
ORDER BY
t1.menu_root_id, t1.menu_lft

Als Fehlermeldung kommt jetzt: 1054 : Unknown column 't1.menu_id' in 'on
clause', obwohl 'menu_id' in der Tabelle menu (AS t1) definitiv
existiert.