Was ein Versionssprung an der Datenbank wirklich tut

Vor einem Versionssprung wird gefragt, wie groß er ist. Die Antworten sind meist qualitativ — „viel", „überschaubar", „größer als der letzte". Wir betreiben beide Linien parallel und konnten die Frage deshalb anders beantworten: Schema gegen Schema, Zeile für Zeile.

Die Zahlen

Die Bereinigung, ohne die die Zahl falsch wäre

Die beiden Runtimes tragen nicht denselben Pluginstand — 5 gegenüber 9 Erweiterungen. Roh gemessen ergab das 29 neue Tabellen. Sechs davon stammen aus Plugins und sind entfernt:

pixup_cheapest_price_cache · pixup_cheapest_price_cache_price · pixup_cheapest_price_product · pixup_cheapest_price_product_price · product_cheapest_price · rankpill_import

Bleiben 23 Kerntabellen. Die Zuordnung lief über die Herkunft der CREATE TABLE-Anweisung: Liegt sie unter vendor/shopware/core/Migration, ist es Kern; liegt sie unter custom/plugins, ist es ein Plugin.

Zweiundzwanzig der 23 stammen aus dem Migrationsverzeichnis V6_7, eine (deleted_apps) aus V6_6 — sie kam in einem späteren 6.6-Patch, den die gemessene 6.6.10.6 noch nicht hatte.

Die neuen Tabellen — und warum sie das kleinere Thema sind

Sie verteilen sich auf vier erkennbare Bereiche: eine Gruppe rund um Maschinenschnittstellen für KI-Werkzeuge (app_mcp_*, mcp_tool_result_cache), eine für Einwilligungen (consent_log, consent_state), eine für Webhooks (webhook_delivery, webhook_stream) und eine für Maßeinheiten (measurement_system*, measurement_display_unit*). Dazu Einzelstücke wie document_file, theme_runtime_config, oauth_user und sales_channel_tracking_*.

Neue Tabellen brechen nichts. Eine Integration, die sie nicht kennt, merkt nichts von ihnen. Sie sind interessant für die Frage, was Shopware vorhat — nicht für die Frage, was beim Update kaputtgeht.

Die drei entfallenen Spalten

Hier wird es ernst:

Die erste ist die folgenreichste. Ein System, das Kunden anlegt oder aktualisiert und dabei eine Standardzahlart mitschickt, schreibt ab 6.7 in ein Feld, das es nicht mehr gibt. Je nach Zugriffsweg endet das mit einem Fehler oder — unangenehmer — mit einem stillschweigend ignorierten Wert.

Die zwölf Typänderungen

Nicht alle sind gleich gefährlich. Sortiert nach Risiko:

Aus NULL wird Pflicht

Das ist die Klasse, die schreibende Integrationen bricht. Wer eine Zahlart oder Versandart ohne technischen Namen anlegt, kam in 6.6 durch. In 6.7 nicht mehr. Der Code ist unverändert, das Verhalten nicht.

Zahlentypen

Der Wechsel von int auf double bei den Preisfeldern der Lieferposition ist die auffälligste Änderung der Liste. Wer diese Spalten direkt ausliest — etwa in einem Reporting neben Shopware — sollte den Typ nachziehen.

Das Gewicht bekommt mehr Nachkommastellen. Für ein System, das Gewichte zurückschreibt und dabei rundet, ändert sich die Erwartung.

Harmlose Verbreiterungen

customer_address.first_name und .last_name sowie die entsprechenden Felder in order_address wachsen von 50 bzw. 60 auf 255 Zeichen; product.display_group von 50 auf 64. Wer diese Felder in einem eigenen Schema spiegelt, sollte nachziehen — kaputt geht dabei nichts.

Die 47 neuen Spalten, nach Tabelle

Die vollständige Verteilung, weil die Auswahl mehr sagt als die Summe:

Dreizehn weitere Tabellen bekommen je eine Spalte dazu:

Drei davon sind eigene Themen wert: product.type führt Produkttypen ein, custom_field.include_in_search öffnet Custom Fields für die Suche, und die primären Verweise am order ändern, wie Integrationen an Lieferung und Transaktion kommen — Die primäre Transaktion einer Bestellung.

Was aus diesem Delta nicht folgt

Der wichtigste Abschnitt, weil Schema-Vergleiche zum Überinterpretieren einladen:

Kein Zeitaufwand. Die Zahl der Änderungen sagt nichts darüber, wie lange ein Update dauert. Das hängt an der Datenmenge und an den Migrationen, nicht an der Zahl der Spalten.

Kein Risiko für Ihren Shop. Ob eine der drei entfallenen Spalten für Sie zählt, hängt ausschließlich daran, ob etwas darauf zugreift. Bei vielen Shops ist die Antwort nein.

Nichts über Erweiterungen. Ein Schema-Vergleich des Kerns sagt nichts darüber, ob Ihre Plugins mit 6.7 laufen. Das ist die eigentliche Arbeit eines Updates und eine andere Messung.

Nichts über das Verhalten. Eine Spalte existiert — gefüllt wird sie deshalb noch lange nicht. Genau das ist bei den primären Verweisen am order der Fall.

Kein durchgeführtes Update. Wir haben zwei Installationen verglichen, nicht eine aktualisiert. Ein echtes Update kann Zwischenzustände erzeugen, die hier nicht sichtbar sind.

Die Prüfliste, die daraus folgt

Wer von 6.6 auf 6.7 geht und Integrationen betreibt, prüft in dieser Reihenfolge:

1. Schreibt etwas customer.default_payment_method_id? Wenn ja, ist das der erste Fund.
2. Legt etwas Zahlarten, Versandarten oder Import-Profile an? Dann muss ab 6.7 ein technischer Name mitkommen.
3. Liest etwas order_delivery_position direkt aus? Typ von int auf double nachziehen.
4. Spiegelt etwas Namensfelder in ein eigenes Schema? Feldlängen nachziehen.
5. Schreibt etwas einen gelesenen Datensatz vollständig zurück? Dann trifft es zusätzlich description_teaser — das Feld ist neu und schreibgeschützt.

Punkt 5 hat uns in einem eigenen Projekt Credits gekostet, bevor es auffiel.

Ob der Wechsel für Sie ansteht, ist eine andere Frage als die nach dem Schema — sie steht in Auf Shopware 6.7 wechseln oder bei 6.6 bleiben. Wie wir solche Wechsel begleiten, gehört zu Shopware-Agentur.