Row size too large (> 8126)

Llewellyn commented

2019-01-25 22:15:27 +00:00

Owner

Steps to reproduce the issue

Import of the JCB package of Joomla Member Manager

Expected result

That all data just import

Actual result

We get the following 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.

System information (as much as possible)

https://hub.docker.com/r/bitnami/joomla/

Additional comments

Issue was mentioned on the JCB forum

### Steps to reproduce the issue Import of the JCB package of Joomla Member Manager ### Expected result That all data just import ### Actual result We get the following 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. ``` ### System information (as much as possible) https://hub.docker.com/r/bitnami/joomla/ ### Additional comments Issue was mentioned on the [JCB forum](https://groups.google.com/a/vdm.io/forum/#!topic/jcb/eFXqITxNFoU)

Llewellyn commented

2019-01-25 22:19:28 +00:00

Author

Owner

Hmm I can confirm when I install JCB v2.9.8 and then check the ROW_FORMAT it is set to be Compact. This seems to be the default for the InnoDB engine (in some environments), as when I change the tables to MyISAM in JCB (and compile and install) then as MyISAM, then they are by default Dynamic (in some environments).

Okay so this does seem like the issue (ROW_FORMAT)

We can add this to the admin views just like we did with the engine selection. These are the options I have in mind. https://dev.mysql.com/doc/refman/5.5/en/innodb-row-format.html

I am just wondering if the file formats, also needs attention?

Hmm I can confirm when I install JCB v2.9.8 and then check the ROW_FORMAT it is set to be Compact. This seems to be the default for the InnoDB engine (in some environments), as when I change the tables to MyISAM in JCB (and compile and install) then as MyISAM, then they are by default Dynamic (in some environments). Okay so this does seem like the issue (**ROW_FORMAT**) We can add this to the admin views just like we did with the engine selection. These are the options I have in mind. https://dev.mysql.com/doc/refman/5.5/en/innodb-row-format.html I am just wondering if the **file formats**, also needs attention?

TLWebdesign commented

2019-01-25 23:32:14 +00:00

(Migrated from github.com)

Author

Owner

From what i read on the interwebs is that setting it to dynamic should fix the issue. Also on our own google group it is given as the fix for another similar issue.

TLWebdesign commented

2019-01-26 09:20:35 +00:00

(Migrated from github.com)

Author

Owner

I installed JCB v2.9.9 from staging branch by downloading it from github. Installed it. Went to JCB->Joomla Components->Import JCB Packages->Community Packages->Members manager and tried to install it.

Still giving the same error: 1118 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.

But isn't that to be expected? I mean isn't it using the install.sql from the members manager package? So shouldn't that install.sql be adapted with ROW_FORMAT=DYNAMIC to fix this? And of course have JCB on package generation add ROW_FORMAT=DYNAMIC. SO basically shouldn't you also repackage the members manager component through the updated JCB version and push it to github?

Kind regards,
Tom

I installed JCB v2.9.9 from staging branch by downloading it from github. Installed it. Went to JCB->Joomla Components->Import JCB Packages->Community Packages->Members manager and tried to install it. Still giving the same error: 1118 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. But isn't that to be expected? I mean isn't it using the install.sql from the members manager package? So shouldn't that install.sql be adapted with ROW_FORMAT=DYNAMIC to fix this? And of course have JCB on package generation add ROW_FORMAT=DYNAMIC. SO basically shouldn't you also repackage the members manager component through the updated JCB version and push it to github? Kind regards, Tom

Llewellyn commented

2019-01-26 11:18:01 +00:00

Author

Owner

There is not install.sql in the members manager package. The update to JCB is enough to resolve the issue, as I have tested it a few times with the bitnami stack deployment of Joomla in a docker environment.

What I did is I install JCB v2.9.8 on the Bitnami Joomla website, then I used this link to update it, en then the same old JMM package on gihub, and that package of 48 component and it all just worked, where it did not before, now it does.

You will see in v2.9.9 we have added an sql update script to update all the tables, you should confirm that the tables indeed were updated.

Running that script manually should also work as a fix. Reality is we must convert all the tables to a DYNAMIC row_format, and that script does just that.

There is a way to see all the data being imported from the any JCB package, and that would be to do a dump on line 620:

var_dump($this->data); jexit();

You will see all values are moved as a huge array. and then dynamic imported to resolve all ID conflicts and merge all existing values. This is not small install.sql trick, it is a very complex, yet stable smart and intelligent import process.

There is not install.sql in the members manager package. The update to JCB is enough to resolve the issue, as I have tested it a few times with the [bitnami stack deployment](https://hub.docker.com/r/bitnami/joomla) of Joomla in a docker environment. What I did is I install JCB v2.9.8 on the Bitnami Joomla website, then I used [this link](https://github.com/vdm-io/Joomla-Component-Builder/archive/staging.zip) to update it, en then the same old JMM package on gihub, and that package of 48 component and it all just worked, where it did not before, now it does. You will see in v2.9.9 we have added an [sql update script](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/sql/updates/mysql/2.9.8.sql) to update all the tables, you should confirm that the tables indeed were updated. Running that script manually should also work as a fix. Reality is we must convert all the tables to a DYNAMIC row_format, and that script does just that. There is a way to see all the data being imported from the any JCB package, and that would be to do a dump [on line 620](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/models/import_joomla_components.php#L620): ``` var_dump($this->data); jexit(); ``` You will see all values are moved as a huge array. and then dynamic imported to resolve all ID conflicts and merge all existing values. This is not small install.sql trick, it is a very complex, yet stable smart and intelligent import process.

Llewellyn commented

2019-01-26 11:30:54 +00:00

Author

Owner

O yes and all new installs of JCB (once we release the new update of v2.9.9 or above) will start with the tables set as DYNAMIC row_format.

This page gives you a few pointer on how to check that a table is indeed now using the DYNAMIC row_format.

O yes and all new installs of JCB (once we release the new update of v2.9.9 or above) will start with the tables set as [DYNAMIC row_format](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/sql/install.mysql.utf8.sql#L136). [This page](https://dev.mysql.com/doc/refman/5.7/en/innodb-row-format.html#innodb-row-format-detrmining) gives you a few pointer on how to check that a table is indeed now using the DYNAMIC row_format.

Llewellyn commented

2019-01-26 11:45:30 +00:00

Author

Owner

I for local development use mostly docker, it just take care of so many issue for you if you use the right packages.

I have found Bitnami to be the most trustworthy and over all stable solution, and would mostly run their deployment scripts for the various project, including Joomla. A very nice tool that I found to manage the docker images, and see all the activities with a quick overview is https://portainer.io/

Then I also have a few custom setups, but for testing stuff I prefer if we all would use the same base, and at this point that base is https://hub.docker.com/r/bitnami/joomla (docker also runs on Windows)

The deployment commands are all in a docker file, and work very well. They setup the database and connects it to the Joomla install. You can tweak the docker file to use other passwords and stuff, and with just a few changes, this is also the scripts the AWS uses to deploy real live production environment for Joomla on their more affordable light sail packages. This is what I mostly use for small to medium size projects. So setting up a local development environment that match your production is perfect.

I for local development use mostly docker, it just take care of so many issue for you if you use the right packages. I have found Bitnami to be the most trustworthy and over all stable solution, and would mostly run their deployment scripts for the various project, [including Joomla](https://hub.docker.com/r/bitnami/joomla). A very nice tool that I found to manage the docker images, and see all the activities with a quick overview is https://portainer.io/ Then I also have a few custom setups, but for testing stuff I prefer if we all would use the same base, and at this point that base is https://hub.docker.com/r/bitnami/joomla (docker also runs on Windows) The deployment commands are all in a docker file, and work very well. They setup the database and connects it to the Joomla install. You can tweak the docker file to use other passwords and stuff, and with just a few changes, this is also the scripts the AWS uses to deploy real live production environment for Joomla on their more affordable [light sail packages](https://aws.amazon.com/lightsail/). This is what I mostly use for small to medium size projects. So setting up a local development environment that match your production is perfect.

TLWebdesign commented

2019-01-26 22:35:16 +00:00

(Migrated from github.com)

Author

Owner

Ok yeah it did not change the row_format to dynamic. See screen of phpmyadmin. BTW working on a live domain i use for developing. It's on my own VPS.

Ok yeah it did not change the row_format to dynamic. See screen of phpmyadmin. BTW working on a live domain i use for developing. It's on my own VPS. ![schermafbeelding 2019-01-26 om 23 34 27](https://user-images.githubusercontent.com/4402824/51793593-166b9780-21c3-11e9-8d68-1a200ac0a4ce.png)

TLWebdesign commented

2019-01-26 23:00:15 +00:00

(Migrated from github.com)

Author

Owner

Altering them manually in phpmyadmin give this error;

[Warning: #1478 InnoDB: ROW_FORMAT=DYNAMIC requires innodb_file_format > Antelope.
Warning: #1478 InnoDB: assuming ROW_FORMAT=COMPACT. ]

Which is weird because the documentation says that it needs barracuda instead of antelope. On Mariadb 10.1. Seems to be an issue with my configuration so i guess no further actions needed because it didn't set my tables correctly because of this. Or the script you talk about should be able to set the innodb_file_format too. But that could corrupt things from what i read so i'm not up to that on my live server. If i want to check the members package i'll just use a offline version for now i guess.

https://mariadb.com/kb/en/library/xtradbinnodb-file-format/

Altering them manually in phpmyadmin give this error; ``` [Warning: #1478 InnoDB: ROW_FORMAT=DYNAMIC requires innodb_file_format > Antelope. Warning: #1478 InnoDB: assuming ROW_FORMAT=COMPACT. ] ``` Which is weird because the documentation says that it needs barracuda instead of antelope. On Mariadb 10.1. Seems to be an issue with my configuration so i guess no further actions needed because it didn't set my tables correctly because of this. Or the script you talk about should be able to set the innodb_file_format too. But that could corrupt things from what i read so i'm not up to that on my live server. If i want to check the members package i'll just use a offline version for now i guess. https://mariadb.com/kb/en/library/xtradbinnodb-file-format/

Llewellyn commented

2019-01-27 18:32:50 +00:00

Author

Owner

That may be why the JCB update did not update them. It seems like you will have to ask your hosting provider to look into this, as this is a wrong system setting. Well anyway I can be wrong, but asking them to take a look will help I am sure.

👍 1

TLWebdesign commented

2019-01-28 12:34:50 +00:00

(Migrated from github.com)

Author

Owner

I'm my own Hosting provider 😄 Installation is just standard directadmin so will ask on their forums. It's definitely related to this it not being updated. No worries. Will look into it and make the necessary adjustments to my server but not at the moment because having it break down is not something i look forward too in these busy times. hihi Thanks for the support

fred-the-coder commented

2020-06-22 09:13:55 +00:00

(Migrated from github.com)

Author

Owner

@TLWebdesign I have the same issue on my local environment when trying to import one of my JCB package.
I have just installed the latest JCB version, which forces DYNAMIC to row format, but JCB tables row format is still "COMPACT" in my case.
Using InnoDB engine.
How can I solve the issue by forcing row_format to Dynamic, instead of Compact?
Do I have to update MySQL install?

When trying to ALTER on JCB table I had the same error as you i.e.:
Warning: #1478 InnoDB: ROW_FORMAT=DYNAMIC requires innodb_file_format > Antelope.
Warning: #1478 InnoDB: assuming ROW_FORMAT=COMPACT.

Thank you.

@TLWebdesign I have the same issue on my local environment when trying to import one of my JCB package. I have just installed the latest JCB version, which forces DYNAMIC to row format, but JCB tables row format is still "COMPACT" in my case. Using InnoDB engine. How can I solve the issue by forcing row_format to Dynamic, instead of Compact? Do I have to update MySQL install? When trying to ALTER on JCB table I had the same error as you i.e.: Warning: #1478 InnoDB: ROW_FORMAT=DYNAMIC requires innodb_file_format > Antelope. Warning: #1478 InnoDB: assuming ROW_FORMAT=COMPACT. Thank you.

fred-the-coder commented

2020-06-22 10:26:16 +00:00

(Migrated from github.com)

Author

Owner

I reached to solve my issue by updating row_format of JCB tables.

I run this SQL statement first: SET GLOBAL innodb_file_format=Barracuda; (as I had this error previously ROW_FORMAT=DYNAMIC requires innodb_file_format > Antelope.)
Then I run the "optimize" routing on all JCB tables which updated those tables and set the row_format to the one expected at creation, i.e. "DYNAMIC".

Then I was able to import my JCB component correctly!

I reached to solve my issue by updating row_format of JCB tables. I run this SQL statement first: SET GLOBAL innodb_file_format=Barracuda; (as I had this error previously ROW_FORMAT=DYNAMIC requires innodb_file_format > Antelope.) Then I run the "optimize" routing on all JCB tables which updated those tables and set the row_format to the one expected at creation, i.e. "DYNAMIC". Then I was able to import my JCB component correctly!

TLWebdesign commented

2020-07-01 09:32:51 +00:00

(Migrated from github.com)

Author

Owner

Thanks for this @fred-the-coder !

Row size too large (> 8126) #369

Steps to reproduce the issue

Expected result

Actual result

System information (as much as possible)

Additional comments