Ich schlage vor, das Feld "value" von "varchar(255)" in "text" zu ändern.
@discordier Gehen hier bei Contao eventuell Daten verloren?
Sollte keine Probleme machen, jedoch muss man dann einen upgrade step bauen, welcher bestehende Installationen dann auch aendert. Ansonsten bleiben die weiterhin auf varchar und nur neue Attribute kommen in den Genuss der laengeren column. Allgemein ist jedoch die Frage, ob bei einer solchen Laenge nicht das Attribut "longtext" dem use case eher entspricht, denn 255 Zeichen in einem Text input sind schon kaum lesbar, dann doch eher eine textarea und somit longtext, oder nicht?
Ja wäre eine sinnvolle Optimierung. Wenn dann gleich richtig.
welche Nachteile ergeben sich denn?
TEXT and BLOB is stored off the table with the table just having a pointer to the location of the actual storage where VARCHAR is stored inline with the table. VARCHAR is usually faster IF the data is frequently retrieved (included by most queries) which is the case here. If we would not retrieve the data often, TEXT would come in handy but that would render the external table simply a "lookup map" of values. MySQL would have to retrieve all matching rows from the table and later on then the TEXT values from the TEXT file. I fear we will have a speed impact here.
I think increasing the number of the varchar to e.g. 500 is enough. As @discordier mentioned here https://github.com/MetaModels/attribute_tabletext/issues/5#issuecomment-39115272 the user has to choose the longtext field with the textarea when there is a lot of text.
bisher habe ich keine Infos erhalten, dass die 255 Zeichen nicht ausreichen würden - solange kein "dringender" Handlungsbedarf besteht, würde ich die Tabelle erstmal "schmal" halten...
Edit: 255 Zeichen sind es ja nur bei "pure ACSII" bei UTF8 sind ja schon drei Byte je Zeichen
I'd bump this to 2.1 then unless someone is eager to implement it (including the database updater).