Extend length of supported IDs in search API DB Backend

Realistically this should support entity IDs that are as long as the ones that core supports. I looked this up and the example implementation EntityTestStringId uses the basic string data type without any limitation. This means a maximum of 255 characters (ref. StringItem::defaultStorageSettings()).

Then we also need to take into account the maximum length of an entity type machine name and the language code. Both of these can be pretty long. Entity types can be user generated (e.g. node types), and these are typically up to 32 characters. The language code can be for example 'xxx-lolspeak' which is 12 characters.

I think it would be better to split up the parts that make up this ID and store them in dedicated table columns.

The patch is building on the test written for #2671228: Support for arbitrary strings as entity IDs, so let's wait until that is in first.

I completely support this, 50 characters is really very little for our combined IDs. Almost as soon as some entity uses string IDs, this will be too restrictive.
However, unless I'm mistaken, especially with columns in the primary key increasing the size does have its repercussions, so I wouldn't go overboard here. 150 is probably good enough for almost all use cases.
I would have suggested to just use a config setting for determining this, but then we'd always need to adapt the search_api_item.item_id column definition to these changes, which would be really tricky. And a UI would probably be overkill (and might still be problematic).
So yes, let's wait for the other patch to go in, and then commit this.

PS: It seems you (like many others – it's really easy to misinterpret) are confused by the "Issue tags" field. As the guidelines state, they aren't meant for free text tags related to the issue, but only for specific categorization purposes, usually by module maintainers.
So, if you aren't sure your current usage is correct, please just leave the field empty.

Yes indeed 150 characters should be sufficient for 99% of the use cases that Search API supports. If this is surpassed it is going to be a very special use case anyway.

We are such a special snowflake in that we are using URIs as entity IDs which can theoretically be very long (over 2000 characters I believe). In practice we have control over the URIs we generate so we are able to stay within the 150 character limit for content we generate ourselves. If we are forced to go over this limit in the future we'll come up with a custom solution like a lookup table or something.

The other patch is committed, this one still applies. Would you say it's RTBC?
Do we need tests for this?

(Also, we might want to profile at some point whether this doesn't cost too much, performance-wise, in the DB backend. If that's the case, we might want to switch to auto-increment IDs just for the DB backend, and an additional table for translating them back to their real item IDs. But that's a follow-up which can be done at any time.)

Makes sense, thanks!
However, we (currently) don't use the short array syntax in this module, so this should stay consistent.
Also, I don't think using a UUID there is very clear – we can just generate a long string value, that's much more explicit.

Also changing the test data to have labels. Also a nice touch, I think, and we can save the comments that way.

The test-only patch doesn't fail on php7, so we should write a better test.

I think it's not related to PHP 7 but to SQLite data types. I guess they don't have a size restriction on their columns, so item IDs could have had arbitrary length there before, too. (Not too familiar with SQLite, though – but it seems a reasonable assumption, I'd say. I wouldn't know what PHP 7 would have to do with this.)

(Added a test for PHP 7 and MySQL to verify this hypothesis. Also one for PHP 7 and Postgres, because I'm stupid.)

Cool, thanks!

OK, then. Committed.
Thanks again, everyone!