field_sql_storage_schema() exposes the schema of dynamic field data tables.
That's a *lot* of data in drupal_get_schema(), and computing it from configuration data on sites with lots of fields takes some CPU too.
Discussing with various people (@effulgentsia, @chx, @fago), it seems no-one sees the interest of exposing the schema for those tables. We don't ever use drupal_write_record() on those.
@DamZ pointed that ctools D7 uses the 'foreign keys' schema entries to auto-generate relationships - but it reads those from each individual field's hook_field_schema() rather than from drupal_schema()
Thoughts ?
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | rm-field_sql_storage_schema-1957204-3.patch | 4.18 KB | yched |
| #3 | interdiff.txt | 3 KB | yched |
| #1 | rm-field_sql_storage_schema-1957204-1.patch | 915 bytes | yched |
Comments
Comment #1
yched commentedCandidate patch, to get the ball rolling.
Comment #3
yched commented#1167144: Make cache backends responsible for their own storage has bitten the bullet and turned cache tables for SQL backends into field-like dynamic tables, that are not exposed in hook_schema(). So I guess it's open season :-)
Fixed the tests that relied on the schema.
Comment #4
chx commentedGreat idea.
Comment #5
yched commentedTagging
Comment #6
catchThe only reason to have these in hook_schema() would be to compare them with schema module.
However if absolutely necessary schema module could add them back with hook_schema_alter() itself anyway, so I don't see the point.
This is going to make a big difference to the schema cache generation on misses, very nice.
Committed/pushed to 8.x, thanks!
Comment #7.0
(not verified) commentedremove cruft