Maximalanzahl an Spalten für s_articles_atributes?

Hallo liebe shopware - Gemeinde,

beim Update eines Shopware Plugins kam folgende Meldung beim “Alter Table” - Befehl (also wo er versucht hat, das neue Feld / die neue Tabellenspalte zur Tabelle hinzuzufügen):

Unable to install, got exception: An exception occurred while executing 'ALTER TABLE `s_articles_attributes` ADD `attr_field` VARCHAR(500) NULL DEFAULT NULL': SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs 

. Das Update beinhaltet das Hinzufügen weiterer Artikel - Attributfelder über:

$service = $this->get('shopware_attribute.crud_service');
$service->update(
     's_articles_attributes',
     'attr_field',
     'string',
     [
          'label' => 'Feld',
          'supportText' => '',
          'helpText' => 'Feld',
          'translatable' => true,
          'displayInBackend' => true,
          'position' => 1,
          'custom' => false
     ]
);

Als “Vorschlag” kam, andere Datentypen zu nehmen (Blob, etc.). Nur legt das neue Attributsystem von Shopware ja die Datentypen selbst fest, siehe:

Attribute system . Also was nun? Gibt es eine Maximalanzahl an Spalten seitens Shopware oder was wäre ein “Workaround” für so einen Fall? Oder soll man jetzt einfach überall “text” statt “string” nehmen, auch wenn es bei dem Feld nicht unbedingt Sinn macht? [@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”)‍

Beste Grüße

Sebastian

 

 

 

Hallo,

hat keiner eine Idee oder ein “Workaround” für die Problematik? Es dürfte ja, wenn man Pech hat, jedes Shopware Plugin betreffen können, das Artikel-Attributsfelder nutzt (vorausgesetzt, es sind in dem Onlineshop viele weitere Plugins, die auch Artikel-Attributsfelder nutzen und implementieren).

Beste Grüße

Sebastian

Hi,

kannst du eben eine Übersicht der Spalten zeigen: 

show full columns from s_articles_attributes

Zwar kannst du theoretisch einige tausend Spalten haben - die dürfen insgesamt aber nicht mehr als 65535 haben. Entweder sind die Freitextfelder dazu „großzügig“ - oder du hast zu viele zu große Felder. Da wäre ganz gut zu sehen, was da in der Praxis bei dir so los ist.

Danke schonmal!

Daniel

@Daniel Nögel schrieb:

Hi,

kannst du eben eine Übersicht der Spalten zeigen: 

show full columns from s_articles_attributes

Zwar kannst du theoretisch einige tausend Spalten haben - die dürfen insgesamt aber nicht mehr als 65535 haben. Entweder sind die Freitextfelder dazu „großzügig“ - oder du hast zu viele zu große Felder. Da wäre ganz gut zu sehen, was da in der Praxis bei dir so los ist.

Danke schonmal!

Daniel

Hallo Daniel,

vielen Dank schonmal für deine Antwort.

Die Screenshots zu deinem SQL-Kommando wären:

http://www.bilder-upload.eu/show.php?file=64b25e-1474396392.jpg

http://www.bilder-upload.eu/show.php?file=45d6fb-1474396437.jpg

http://www.bilder-upload.eu/show.php?file=65f9eb-1474396459.jpg

Anzumerken wäre, das es sich hier um einen Demoshop handelt - es kann aber durchaus sein, dass ein Käufer einmal alle Plugins erwirbt, was nicht ungewöhnlich wäre.

Die 65535 sind eben durch das neue Attributsystem aus meiner Sicht das Problem - ich würde bei vielen Feldern, die jetzt „string“ nutzen, überhaupt nicht die VARCHAR(500) nutzen (sondern vielleicht nur ein Fünftel), nur setzt das neue Attributsystem den Wert bzw. Datentyp ja von allein. Und da ich in dem Fall beispielsweise auch das Textfeld (Inputfeld) anbieten möchte, muss ich ja " string" ( VARCHAR(500) ) nehmen. Und für ein TinyMCE-Feld muss man ja auch html (MEDIUMTEXT) nutzen, genauso wie bei einem Combobox-Feld combo (MEDIUMTEXT). Viel ändern kann ich da also von Hause auch nicht, weil Shopware ja die Datentypen und dessen Größe selbst setzt.

 

Das Problem vorallem: bei einem Update kamen bei einem Plugin nun neue Attribut-Freitextfelder hinzu, da kommt aber automatisch die oben genannte Fehlermeldung. Einzige Lösung: ich musste ein anderes Plugin (mit Artikel-Attributfeldern) löschen, damit ich „Platz“ für neue hatte. Das nun einem Käufer zu erklären wird schwierig, vor allem wenn es um ein Update geht.

Es kann ja auch durchaus sein, das eben schon soviele Artikel-Attributfelder beim Käufer vorhanden sind, das die Installation mit der oben genannten Fehlermeldung fehlschlägt - nun kann er das Plugin aus diesem Grund nicht installieren, obwohl das Plugin ja funktioniert bzw. funktionieren würde. Und was nun? Geld zurück, obwohl das Plugin nicht „schuld“ ist, sondern die Vielzahl an anderen Plugins mit Artikel-Attributfeldern?

 

Die angesprochenen Plugins bieten eben auch die höchstmögliche Flexibilität - deshalb kann man vieles individuell pro Artikel festlegen, was natürlich auch viele Artikel-Freitextfelder zur Folge hat.

Beste Grüße

Sebastian

Hi,

ja, sehe ich wie du. Habe gerade ein Ticket dazu gefunden: Shopware Issuetracker - habe mal auf den Thread hier verlinkt. 

Besten Gruß,

Daniel

@Daniel Nögel schrieb:

Hi,

ja, sehe ich wie du. Habe gerade ein Ticket dazu gefunden: https://issues.shopware.com/#/issues/SW-15674 - habe mal auf den Thread hier verlinkt. 

Besten Gruß,

Daniel

Hallo,

mir geht es ja auch überwiegend darum: was soll man dem Käufer bei der Installation oder viel schlimmer dem Käufer bei einem Update sagen, das zusätzliche Artikel-Attributfelder mitbringt (das betrifft ja nunmal auch Shopware selbst bzw. den Shopware Store)? Lösch ein anderes Plugin, damit du die Installation oder das Update durchführen kannst? Wie soll man das „Problem“ bei einem Käufer / Nutzen lösen, manuell per SQL andere Felder verkleinern?

Ich habe das von dir angesprochene Ticket auch einmal kommentiert und gevotet, damit das Thema von Shopware vielleicht einmal beleuchtet wird.

Beste Grüße

Sebastian

Hi @sschreier‍,

habe das Thema nochmal an die Core-Jungs gegeben, die schauen sich das im Detail an. Vollautomatisiert kannst du da als Plugin-Dev ja eigentlich nichts machen - du weißt ja nicht, ob und wofür der Nutzer die Spalten benötigt. Am ehesten könnte man ihn in einer Hinweismeldung darum bitten, nicht benötigte Freitextfelder zu entfernen. Wie gesagt: Wir schauen uns das an. 

Danke für den Hinweis auf jeden Fall schonmal!

Besten Gruß,

Daniel

1 „Gefällt mir“

@Daniel Nögel schrieb:

Hi @sschreier‍,

habe das Thema nochmal an die Core-Jungs gegeben, die schauen sich das im Detail an. Vollautomatisiert kannst du da als Plugin-Dev ja eigentlich nichts machen - du weißt ja nicht, ob und wofür der Nutzer die Spalten benötigt. Am ehesten könnte man ihn in einer Hinweismeldung darum bitten, nicht benötigte Freitextfelder zu entfernen. Wie gesagt: Wir schauen uns das an. 

Danke für den Hinweis auf jeden Fall schonmal!

Besten Gruß,

Daniel

Hallo Daniel,

ich danke dir für die Hilfe und die Information.

Eventuell könnte man überlegen, wenn man das Attribut-Freitextfeld erzeugt hat, es im Nachhinein über ein SQL-Statement beispielsweise von VARCHAR(500) auf VARCHAR(100) zu ändern, damit die Felder nicht unnötig groß werden, wenn es nicht unbedingt notwendig ist (dies geht natürlich nur, wenn die Maximalgröße davor nicht schon erreicht war). Dies kann man ja auch über ein Plugin-Update nachschieben. Oder man bietet bei $service->update(…) noch die Möglichkeit an, neben „string“ auch die Größe des Datentyps optional festlegen zu können (Standard: 500, Optional: 100).

Ein Beispiel wäre: ich möchte gern beim Artikel ein Startdatum festlegen lassen und nutze dazu ein Textfeld („string“ -> VARCHAR(500) ), da das Feld neben „21.09.2016“ auch „+1“ aufnehmen kann. Nun „blockiert“ das Feld 500 Zeichen, auch wenn es 50 oder 100 auch getan hätten. So bläht es natürlich die Tabelle ordentlich auf.

Wie gesagt, sicher ein „Extremfall“, wenn wirklich viele Plugins mit zusätzlichen Artikel-Freitextfeldern genutzt werden - aber eben kein unwahrscheinlicher Fall wie oben erwähnt.

Die attr1-20 - Felder von Shopware blähen natürlich die Tabelle auch ordentlich auf, auch wenn Sie vielleicht überhaupt nicht genutzt werden, nur sind Sie bei einem Update von 5.1 auf 5.2 nunmal automatisch mit übernommen worden.

Beste Grüße

Sebastian

 

Hi,

genau, sowas haben wir auch gerade diskutiert. Denkbar wäre (wie du ja auch schon schreibst), spezifische, kleinere Feldtypen zu schaffen oder Feldtypen zu nehmen, die MySQL anders verwalten kann (das scheint ja bspw. für Blob so zu sein). Außerdem könnte / sollte man die Standard-Freitextfelder nochmal in Frage stellen - das wäre aber so oder so für viele Kunden ein starker Bruch, also nichts, was man kurzfristig umsetzen könnte. Aber das sind vermutlich erstmal die Möglichkeiten, die man diskutieren sollte, das stimmt schon.

Besten Gruß,

Daniel

1 „Gefällt mir“

Hallo! Ich habe das gelöst indem ich der Datenbank gesagt habe, VARCHARD(50) und gut ist. Also mir manuell kleinere eingefügt.
Wird das an einem bestimmten Punkt mit Update etc wieder überschrieben? eigentlich ja nicht oder?