EZEE-3003: Increased ezpage_attributes.value size limit

[webhdx]

JIRA: https://issues.ibexa.co/browse/EZEE-3003

Description

This PR fixes issue where big Landing Page cannot be saved because size limit on ezpage_attribues.value column is exceeded. It usually happens on long Code Block or more advanced Schedule Block configurations.

The solution to that issue is changing column type to LONGTEXT which maxes out at 4GB. MEDIUMTEXT (16MB) could be a good choice but you never know what's going on in client databases... Postgres is not affected because TEXT type has no size limit there.

Upgrade guide

That change requires altering column configuration on current installations:

MySQL/MariaDB

ALTER TABLE ezpage_attributes MODIFY value LONGTEXT;

Postgres

No changes needed.

[webhdx]

@ezsystems/documentation-team please note this PR is dedicated for 2.5 release which means we have to enclose the upgrade script in the documentation.

[Steveb-p]

LGTM, although I'd rather go for MEDIUMTEXT.

For two reasons:

1. Columns of such width will cause the customer's database to fill up space extremely quickly in case of an error.
2. Texts of that size will not fit into PHP's memory anyway in most cases - and even when they do, they will starve the server out of resources.

[webhdx]

1. It will only fill space when you actually start writing big strings to that table. It means you have to be absolutely sure about what are you doing. What kind of "errors" are you talking about? Can you imagine the situation where it writes 4GB because of our mistake? It's more relistic that it will only occur in 3rd party code.
2. So that we should let PHP handle it. If there is a lower limit somewhere it should be handled on the other level. We should not limit the database because PHP has its limits.

4GB is better choice here because we have to choose between 16MB and 4GB. 16MB is still a lot but I can image someone trying to write base64 encoded files or very large JSONs in it which could easily exceed 17MB and still be well below PHP capacity. Of course this is an example of very bad architecture but sadly this kind of stuff happens on integrators' side and then it gets reported as a bug in our software.

[mnocon]

Tested on 2.5 and 3.2, on both PostgreSQL and MySQL using a clean installation and upgrading an existing one (on MySQL).

I was able to enter large fragments of text (https://pastebin.com/WEa8FWAr) into the Code block and the upgrade procedure did not brek the existing block attribute entries.

QA Approved.

[lserwatka]

Thank you @mnocon ! Merging

[lserwatka]

Could you merge it up?