Consider generalizing DefaultTableMapping

Created on 3 January 2015, over 10 years ago

Updated 24 April 2025, 2 days ago

@effulgentsia wrote in #2326719-26: Move pseudo-private table mapping functions from ContentEntityDatabaseStorage to public API of DefaultTableMapping → :

[Let's think] through what kinds of implementation choices we want to allow vs. what we want callers to be able to rely on. Here's some of my initial thinking on that:

It is already part of the Entity Field API that field values can vary by revision and language, and nothing else, so I think it's okay to bake the concepts of revisions and language into the table mapping API.

It is already part of the Entity Field API that field items can consist of multiple columns, as defined by FieldItemInterface::schema() (maybe in the future, columns will be determinable entirely from FieldItemInterface::propertyDefinitions(), but I think this issue can ignore that for now).

I suggest that for any given field, all table mapping implementations MUST provide one table that contains all of that field's values for a given field (i.e., for all revisions and all languages for which a value exists). In other words, it can't solely provide different tables per-revision or per-language without also providing one table with all of the data. I think we need this requirement to support Views.

I suggest that for any given field, table mapping implementations MAY provide additional tables for either the default revision only, or the default language only, or both. In HEAD, we do this for default revision, but not for default language, but alternate implementations should be able to explore other permutations, and be able to make different choices on a per-field basis. Note that any data in these tables is a duplicate of what's also available in the full table, but these smaller tables allow for more efficient JOIN queries.

We might want to consider also allowing table mapping implementations to provide additional tables for a specific revision or a specific language (i.e., just for revision 2 or language 'en', as opposed to just the default ones).

I suggest that table mapping implementations MAY combine multiple fields into a single table, however they want. For example, fields a and b into table x, field c into table y, and fields d, e, and f into table z, etc. And that the combination MAY vary per-table (i.e., fields can be in separate tables for the cross-revision table, fields a and b combined in the default-revision-only table, and fields a and c combined in the default-language-only table).

I suggest that if a field appears in multiple tables, then all of its columns MUST exist in each of those tables, and be named the same in each of those tables (I think that would make the API simpler, and that there's no good use case for deviating from that).

📌 Task

Status

Postponed: needs info

Version

11.0 🔥

Component

entity system

Created by

🇮🇹Italy plach Venezia

Live updates comments and jobs are added and updated live.

entity storage

stale-issue-cleanup
To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Incomplete comments

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment 2 days ago →
🇺🇸United States smustgrave
Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024