10,000 characters = 1,600 words or 3.5 pages single-spaced

https://foundant.helpjuice.com/77470-forms/229310-how-many-pages-is-10-000-characters

This is not as much as it seems. If we are talking about a repeatable field that contains an editor. In this case, we also need to spend symbols on html markup.

JSON is a good format and Joomla makes great use of it.

My real life example when I ran into this limitation:

The goal is to add a unique set of tabs to each article. Different for each article. Joomla out of the box allowed me to solve this problem elegant. I have created a repeatable field and subform with editor and textbox (tab title). Thus, we got a user-friendly interface for adding any sets of tabs to articles. But here 10k characters turned out to be very few, because for 5-6 tabs, we cannot add even one page of text for each.

From what I see, we can close this issue for now. If the change is needed, the author can make this change on his own site. @laoneo Could you please take a quick look to see if it is OK to close this issue?

Honestly the repeatable field should be implemented the same way as the list, that every entry has it's own row. That should be changed instead making the column type bigger.

I guess somebody with more DB experience should answer this. As I fear there would be a performance/resource impact when you have thousands of rows with bigtext. Changing this makes only sense when you have actual that big data. It is a big overhead when you have a bigtet column and all you are storing is either 0 or 1 for checkboxes. @richard67 can we change here to a bigger type?

can we change here to a bigger type?

@laoneo On PostgreSQL we use the "TEXT" data type, which for this kind of database means "string of any length", so nothing to do for PostgreSQL.

For MySQL (and MariaDB) we currently use "TEXT".

We could use the next bigger subtype "MEDIUMTEXT", which we already use at a few other places for params or options.

We could also use the biggest one "LONGTEXT", but we do not do that anywhere else up to now, and if for some reason the utf8mb4 conversion hasn't taken place yet (what should never be the case on a J4 but who knows ...), then MySQL (or MariaDB) might enlarge the data type to the next bigger one in case of possible data loss, and that would not be possible if we already use the biggest possible.

In any case, all kinds of text columns seem to cause a certain overhead because physically stored outside of the table row, so an enlargement from "TEXT" to "MEDIUMTEXT" would not change anything.

The limitations on sorting by that column mentioned here https://dev.mysql.com/doc/refman/8.0/en/blob.html won't apply to us because I don't think we ever sort by that column.

So I think we can make a PR to enlarge it from "TEXT" to "MEDIUMTEXT" for MySQL if that is desired.

But I don't want to decide that alone, I'd like to have more opinions.

Should we change field type to mediumtext now? As @wedal wrote non-latin languages texts are saved in unicode and this limit is strong decrease symbols limit.

Should we change field type to mediumtext now? As @wedal wrote non-latin languages texts are saved in unicode and this limit is strong decrease symbols limit.

@HLeithner Could be something for 5.0. What do you think?

@HLeithner Could be something for 5.0. What do you think?

What are the reasons preventing you from doing this now? Is this a change breaking backward compatibility?

I think isn't

For mysql it doesn't matter much (only the length counter has a byte one more) if we have text or mediumtext it's just longer, default max packet size is 64 MiB so also not a problem.

The main problem with customfield and the single value column is that everything is a text, it would be much nicer to have separate tables or maybe columns for different data types (int, date, char, text, blob). Also I think Text is the worst column type for performance reason, because mysql has to handle the charset encoding, which wouldn't be needed with blob. It also doesn't allow us to have an index on the value column.

In this case, more drastic changes can really be transferred to Joomla 5. And you can change the field type to medium text even now, since there is no fundamental difference (except for increasing the size of the stored data).

possible in 4.4, not sure if we have the resources to change custom fields to have a better database layout before 5.0 goes into beta.

possible in 4.4, not sure if we have the resources to change custom fields to have a better database layout before 5.0 goes into beta.

ok, I'll make a PR

Closing as having a pull request. Please test #42606 . Thanks in advance.