Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

General Questions

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

[Solved] Row size too large (> 8126)


Reply

3 Posts   2197 Views

Avatar
bxxxxx

26 January 2014 at 3:50am Community Member, 8 Posts

Hi there,

I created a *very large* object containing about 20 different Text-Fields.
When saving the object, I get the error:

Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.

The messages tells me, that in the current configuration each of the Text-Fields stores 768 bytes inline and then the total allowed 8126 per row is exceeded.

Is there a way to tell Silverstripe to configure some table as innodb ROW_FORMAT = dynamic and keep the object structure?

What happens, if I do this on the database level (mysql) and make Silverstripe rebuild the structure (dev/build after model changes)?

Or maybe, is there any other solution for this problem?

Thanks in advance
and best regards

Stefan

Avatar
bxxxxx

3 February 2014 at 11:42pm Community Member, 8 Posts

The answer by myself:

I did it on the database level.

1. Make a database_dump and stop the SQL engine

2. The DB has to be configured Like:

in my.cnf section [mysqld|

innodb_file_per_table
innodb_file_format = Barracuda

3. Restart the SQL server

4. Fire the following SQL for every table which is affected:

ALTER TABLE %%Name%%
ENGINE=InnoDB
ROW_FORMAT=COMPRESSED
KEY_BLOCK_SIZE=8;

Do not forget to alter also %%Name%%_Live , %%Name%%_versions if the affected table is Sitetree based.

The /dev/build command keeps this configuration unchanged.

The database backup is for your own insurance. Mysql changes the file structure of the databases on the fly.
Be aware, that the configuration is enabled for all databases on your machine.

Avatar
sirocco

11 June 2014 at 10:21pm Community Member, 11 Posts

Hi there.

Thanks for that resolution. I also ran into this issue on a test SS v3.1.5 install. I note that the same issue does not exist on SS 2.x (same reproduction steps successfully allowed saving of data - SS version was only difference between two tests, no DB config changes or similar.)