@laoneo Can you take a look and check whether context column is long enough?

I guess for most extensions it is enough, but as soon as you wont start to do more advanced things I guess the context can grow.
Under which circumstances does this happen, when the default ROW_FORMAT value of mysql is set to compact? Never saw that issue before, so wondering what is the cause of it.

https://dev.mysql.com/doc/refman/5.6/en/innodb-row-format-antelope.html

To preserve compatibility with prior versions of InnoDB, InnoDB tables created in MySQL 5.6 default to the COMPACT row format rather than the newer DYNAMIC row format.

So what do we do here then? We had this problem discussed already in another issue, but can't remember the number. Honestly I would not go less that 255 characters in the context column.

I can change it to max 191 characters, and it still be OK.
I have changed it to 50 because I found such column name in other table which has 50.

Why: 191* 4 (bytes utf8) = 764 < 767 bytes.

The simpler way may be to set column as LATIN1 or ASCII then there won't be any limit.

Would this be the only place where we have indexes on varchar(255) columns? Just wondering if we don't have that issue somewhere else.

For now yes, the similar is session_id in #__sessions. Others column use some limit in chars to fit.

What's the solution there?

In general I see 3 options:

• leave 255 and change characters coding to 1 byte, like ASCII, latin1
• leave 255 and set/force for table ROW_FORMAT=DYNAMIC (it may be non B/C for older mysql)
• set max 191 chars as it is done in #__sessions table, session_id

Then I would go for option 1 if that is acceptable in the Joomla land.

OK, then can someone approve option 1. I would prefer ASCII as it is a subset of utf8.

The simpler way may be to set column as LATIN1 or ASCII then there won't be any limit.
for me simple is better
?

Move to 191. That's how we should be doing it like the alias in most extensions after 3.6

We are not talking about the alias, its the context field which should not get truncated under every circumstance.

I'm with George.
There is no reason to have a context length of 255 to begin with, 191 will be far more than enough and solves our issue without introducing inconsistencies into the system.
Very likely 50 would be enough as well. It is the length of the context field in #__associations (which is a similar, but not exactly the same context). I'm fine with 50 as well. Honestly if an extension has a context longer than that, then it likely did something worng.

When an extension will have dynamic contextes (similar to a CCK), then it will become very likely to get a context bigger than 50. If there is a way to leave it with 255, and fix the issue, then we should go that way.

When an extension will have dynamic contextes (similar to a CCK), then it will become very likely to get a context bigger than 50.

191 will be far than enough then. Besides, CCKs likely will not use com_fields anyway. They offer that functionality themself.

If there is a way to leave it with 255, and fix the issue, then we should go that way.

Changing charset to ascii would mean we have a single field which isn't utf8mb4. Doesn't sound like a good approach to me.

After all I took a decision to leave for column 255 chars and shrink index key to first 191 characters.

In postgresql I could not set only a few columns to different character set.
There is only one possibility for all varchar/text columns - UTF-8.

@laoneo It would be good to remove #__fields_categories table from sql files and related php code.

Why? This is needed.

I thought that #__fields_categories table is not used any more.

Its the mapping table between a field and a category.

Thanks for explanation, I have not know that.

Could we have some testers here, so that we can add it to the RC1, thanks