Bug #16774
closed
content field of fe_session_data should use mediumtext instead of mediumblob
0%
Description
As far as I can tell, only string data is stored in the content field of the fe_session_data table. I don't understand why mediumblob was chosen as data type.
Mediumtext should do just fine for text.
Problems arise when installing on postgres.
The mediumblob gets cast to a bytea.
This gives me problems when selecting from the content field from within xforms ;-).
#- Table structure for table 'fe_session_data'
#
CREATE TABLE fe_session_data (
hash varchar(32) DEFAULT '' NOT NULL,
content mediumblob NOT NULL,
tstamp int(11) unsigned DEFAULT '0' NOT NULL,
PRIMARY KEY (hash)
);
Should read:
#- Table structure for table 'fe_session_data'
#
CREATE TABLE fe_session_data (
hash varchar(32) DEFAULT '' NOT NULL,
content mediumtext NOT NULL,
tstamp int(11) unsigned DEFAULT '0' NOT NULL,
PRIMARY KEY (hash)
);
(issue imported from #M4628)
Files
Updated by Michiel Roos almost 18 years ago
The same goes for:
- pages_language_overlay: l18n_diffsource
- tt_content: l18n_diffsource
- cache_pages: HTML, cache_data
Please find a patch against ext_tables.sql attached.
Updated by Michiel Roos almost 18 years ago
And it also goes for t3lib/stddb/tables.sql:
All fields just contain text, no binary data.
Find patch attached.
Updated by Michiel Roos almost 18 years ago
These diffs wer pulled from 4.0.3 by the way.
Updated by Michiel Roos almost 18 years ago
And a week ago I discovered that this goes for (allmost?) all '*blob' fields. Maybe the producer of the original sql schema can enlighten us here.
Is there indeed any field in any TYPO3 table where binary data is stored? The fe_user and be_user 'uc' field seem to store binary data?
The rest of the *blob fields may be replaced by *text fields.
I know too little about TYPO3 to judge the content of some fields called 'media' which are of type blob.
Find all the sql schemas in the source tree: grep -rli blob * | grep sql
Updated by Martin Kutschker almost 17 years ago
As the session data column contains a serialized array it must stay a BLOB.
Updated by Christian Kuhn over 14 years ago
Resolved, no change required:
Reason for those blob fields: They are charset independent and as such don't cause any charset issues. Serialized arrays / object are binary data, so blob is the right choice from a mysql point of view. Maybe we could change this if we ever manage to fix all db connection / definition / backwards compatibility issues with this, but this should probably go to some other ticket.
Updated by