panels_common_cache_set: invalid identifier 'did'

It's actually not that easy. Having no valid identifier for panel pages (resp. mini panels) means two instances of the same session can't discriminate two different panel pages: If two panel pages are being edited in separate browser tabs, their data will be mutually overwritten.

We should actually make our cache table more generic, and it would surely be a good idea to adopt the table layout of the main Drupal cache tables, just as Views and other modules do. Also, we should rename our cache table from panels_object_cache to cache_panels to be consistent and to ease up truncating the cache.

This is critical because if we want to do this that late, we need to do it now. I'm in favor.

Yeah, taking over views_object_cache's schema would make sense. I hit this bug while working on #264868: Store imported $page/$mini in cache not in $_SESSION
If you support that change, I'll do a patch tonight!

Here's a patch that changes the table definition for panels_object_cache to allow for a more generic object storage.

Mainly, the following is done:

ALTER TABLE {panels_object_cache} DROP INDEX sid;
ALTER TABLE {panels_object_cache} CHANGE did name varchar(128) AFTER obj;
ALTER TABLE {panels_object_cache} MODIFY obj varchar(64);
ALTER TABLE {panels_object_cache} CHANGE timestamp updated int(11) unsigned NOT NULL DEFAULT 0;
ALTER TABLE {panels_object_cache} MODIFY data blob;
ALTER TABLE {panels_object_cache} ADD PRIMARY KEY (sid, obj, name);

I renamed the field 'did' to 'name' to reflect the more generic content.

It turned out to be a problem that panel_page.name is 255 chars long: To store panel_page.name in panels_object_cache.name the latter would also have to be 255 chars long. But this would be too long for panels_object_cache's composite index.
I therefore settled for 128 chars and changed this in panel_page.name as well. This is no problem as the corresponding name field panels_page_edit_form (by default) has a #maxlength of 128 chars. I made this default property explicit, as it isn't obvious.
The same applies for panel_mini.

For consistency and performance reasons I resized panel_page.name and panel_mini.name to 128 chars. Even smaller would be better performancewise - IMHO 64 or even 32 chars should be enough -- hey, this is the internal name.

For the same index reason, obj had to be reduced to 64 chars. This should be enough though. Do you think, 32 chars would also be enough? We're using not more than 23 chars, do we need to expect custom client modules using more?

'timestamp' was renamed to 'updated' as that field name is used in views and is more descriptive. I also added 'unsigned NOT NULL default 0'.

'data' was changed from text to blob (resp. bytea in pgsql). It is also used in views and should be a bit more performant.

Also I made our composite key the Primary key to improve reliability.

For several reasons the table had to be truncated. This should be no problem though, as cached data doesn't need to be preserved over an update.

The patch has been tested on my Drupal installation on MySQL 5, but not on MySQL 4 and only rudimentary on PgSQL 7.4 and 8.0.

Todo:
- decide if panel_page.name and panel_mini.name, and subsequently panels_object_cache.name should be downsized to 64 or even 32 chars.
- decide if panels_object_cache.obj should be downsized to 32 chars.
- extensive testing, including performance.

Needs some work as in some cases duplicate entries are set. Now that our cache table has a Unique key, this throws a warning. That's a good sign though, as can now be aware of data integrity breaks.