[TYPO3-german] Upgrade von 4.2.3 auf 4.4.2

Stephan Schuler Stephan.Schuler at netlogix.de
Thu Sep 23 15:20:02 CEST 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hallo zusammen,
Hallo Jonas.


Mir will deine Lösung nicht so recht in den Kopf.


Ein Update von 4.2.3 auf 4.4.2 ändert keine UIDs, zumindest nicht von tt_content, pages, tx_templavoila_ds oder tx_templavoila_to.

Eine Encodingänderung gleich welcher Art hat auch keinen Einfluss auf UIDs, die bleiben als Integer immer unverändert.

Einfach ein Datenfeld von BLOB auf TEXT (egal welcher Größe) oder anders herum zu ändert hat zunächst mal auch keine Auswirkung, der Inhalt bleibt dabei unverändert.


Der Unterschied zwischen BLOB und TEXT der dir vermutlich zu schaffen macht: TEXT wird beim Encodingwechsel automatisch angepasst, BLOB nicht.
Egal ob durch einen expliziten oder impliziten CAST im SQL-SELECT-Query oder unterschiedlicher Channel- und Speichercodierung (ich kann sehr wohl ohne größere Probleme eine Datenbank mit UTF-8 anlegen aber LATIN ansprechen, sofern ich das an allen notwendigen Stellen konfiguriert hab), wenn es notwendig ist wird die Datenbank den Inhalt vom Quellformat ins Zielformat überführen, egal ob dir das an der Stelle hilft oder Steine in den Weg schmeißt.
BLOB dagegen wird unverändert übertragen da "binary".


Im mysql_dump siehst du das daran, dass BLOB als base64-encodierte Information im Output steht, TEXT im Klartext (dafür mysql-escaped).


Irgend wie hab ich arge zweifel dass du in der Datenbank konsistent das immer gleiche Encoding verwendest. Ich kann (wobei ich nicht wüsste an welcher TYPO3 das "zufällig" hinbekommt) für Connection, Datenbank, Tabelle und Spalte vier vollkommen unterschiedliche Encodings verwenden. Dass mir sowas beim Export auf die Füße fällt darf mich dann allerdings nicht wundern.


Zunächst mal würde mich interessieren von welchen UIDs du eigentlich sprichst. Die TV-unabhängige, dumme Vater-Kind-Beziehung im Seitenbaum (pages.pid = pages.uid) sowie Inhalt zu Seite (tt_content.pid = pages.uid) darf keinesfalls verloren gehen, das sind wie gesagt immer Integer.

Evtl. geht das Templavoila-XML der page kaputt weil ihr Sonderzeichen im XML stehen habt, oder das Templavoila-XML eines FCE-tt_content aus dem gleichen Grund. In dem Fall würde ich mir aber vorher mal intensiv die unterschiedlichen Encodings der Tabellen und Spalten ansehen.


Grundsätzlich halte ich einen Encodingwechsel im laufenden Betrieb immer für eine äußerst schlechte Idee. Man weiß nie welches TEXT-Element eigentlich ein BLOB sein soll oder umgekehrt. Die fatale Situation ist folgende:

In einem BLOB steht ein XML mit Sonderzeichen, vielleicht heißt das Label eines Eingabefelds "Überschrift". Solange das ein BLOB bleibt und niemand auf die Idee einer Konvertierung kommt spielt das keine Rolle.

Wenn das BLOB nun plötzlich als TEXT behandelt wird fangen die Probleme an. Entweder macht jetzt die Datenbank eine Konvertierung (weil in der Datenbank Latin steht, der PHP-Prozess UTF-8 will, deshalb macht die DB Latin=>UTF-8) oder der PHP-Prozess weil die Datenbankverbindung Latin spricht aber PHP intern UTF-8 spricht (dann macht PHP Latin=>UTF-8). Irgend eine dieser Konstellationen sorgt jedenfalls dafür, dass ein überflüssiges utf8_encode über den Text läuft, das bisher mit  UTF-8-Ü in der Datenbank stehende "Überschrift" wird zu einem in UTF-8 nicht darstellbaren Konstrukt (doppel-UTF-8 im Sonderzeichen).
Ab jetzt hat der XML-Parser natürlich keine Chance mehr weil das XML aufgrund der unlesbaren Sonderzeichen (die früher mal Ü waren) nun leider kein XML mehr ist.


Ich würde um jeden Preis vermeiden, das Encoding einer Installation zu drehen. Das kann eigentlich nur schief gehen. Im schlimmsten Fall erzeugt das einen Datenbankinhalt der Teils alt und teils neu codiert ist (also Latin und UTF-8, teilweise beides in unterschiedlichen Spalten einer Tabelle). Dabei hat man natürlich keine Chance durch Angabe eines vorgelagerten Encode- oder Decode-Befehls die Ausgabe gradezuziehen, das korrigiert zwar den einen Teil, zerstört aber den anderen.


Wenn du nach "[TYPO3-german] TYPO3 und Charset-Chaos" suchst, die Situation ist übrigens nicht neu.


Grüße,
Stephan.



Stephan Schuler
Web-Entwickler

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Internet: http://media.netlogix.de

- --
netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Andernacher Straße 53 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: mailto:info at netlogix.de | Internet: http://www.netlogix.de/

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt

- -----Ursprüngliche Nachricht-----


Von: typo3-german-bounces at lists.typo3.org [mailto:typo3-german-bounces at lists.typo3.org] Im Auftrag von Jonas Langenscheidt
Gesendet: Donnerstag, 23. September 2010 14:09
An: German TYPO3 Userlist
Cc: Thomas Stägemann; sw at weisshuhn.de
Betreff: Re: [TYPO3-german] Upgrade von 4.2.3 auf 4.4.2

Hallo Liste,

hier unsere Lösung zum Upgrade von 4.2.8 auf 4.4.2 ohne das die UID's zerstört werden:
Upgrade von 4.2.8 auf 4.4.2

Dump von der Live-Datenbank per Konsole mit Standardeinstellungen ziehen
mysqldump typo_www --quote-names --routines --triggers --add-drop-table --create-options -p
Importieren des Dumps per phpMyAdmin in Dev-Datenbank mit latin1
Den Primärschlüssel der Tabelle cache_hash löschen
ALTER TABLE 'cache_hash' DROP PRIMARY KEY
Neuen Primärschlüssel für die Tabelle cache_hash anlegen
ALTER TABLE 'cache_hash' ADD 'id' int(11) unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY
Aktualisierung der Dev-Datenbank im Install-Tool per Database Analyzer mit "Compare"
Achtung: Datentyp mediumtext zu mediumblob nicht ändern!!!
Exportiere den Seitenbaum vom Wurzelverzeichnis per Rechtsklick als .t3d: Alle Tabellen und unendlich auswählen
Nun im Database-Analyzer die Datentypen mediumtext zu mediumblob aktualisieren
Über den Quixplorer oder ssh die .t3d in den Fileadmin kopieren
Importieren der .t3d-Datei im Wurzelverzeichnis mit folgenden Optionen:
Datensätze aktualisieren
Verbotene Dateierweiterungen dennoch erlauben (z.B. PHP-Skripte)
ALLE UID-Werte erzwingen


Liebe Grüße
Jonas
_______________________________________________
TYPO3-german mailing list
TYPO3-german at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.0.0 (Build 2881)
Charset: Windows-1252

wpUDBQFMm1QEpp0IwsibV8MBCFQaA/9MMAboJjUAX1NHWnAxvF5pDpVVHq8PQVlO
69PgMkCdmOEH7ebpKuWRVRfEtjcKUY4bgcoje2pSzQX/3vnGudqTrGa81qBg2rdt
l9Rz5xgMoM0tTErIVUFdUkEwhrrXxXTeS6mgQGENvLQpA+i0QAN67exVN93dYQoQ
0azVkKU9uQ==
=b6MU
-----END PGP SIGNATURE-----


More information about the TYPO3-german mailing list