Attempting to splitinto some logical chunks. Here's part 1.
The Field SQL Storage API is currently marked as private. The rationale is that in D7 fields are storage-agnostic so using that API in contrib modules introduces storage-specific code that is going to break as soon as a different storage is used. However this does not account for cases where assuming a SQL storage is legitimate for various reasons. The most obvious example is Views, which has an architecture that supports alternative storages, but which is heavily "biased" toward SQL. Another typical situation is custom code perfectly knowing which storage is being used, and relying on that information to achieve better performance in certain cases by querying directly the database. Both of these cases rely on an API that is unlikely to change but isn't guaranteed not to.
Make the Field SQL Storage API a public API, that is confined to the SQL-specific part of the core entity storage API.
This moves the following methods to the (default) table mapping implementation, which is responsible for representing how fields are mapped to tables:
DefaultTableMappingInterface is introduced to deal with the specific implementation for core storage: other storage classes might want to provide completely different ways to deal with SQL tables and implement completely different table layouts (see ). In that case the concepts of dedicated tables would be meaningless.
User interface changes
None, just additions.
|PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 75,565 pass(es).|
|PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 75,238 pass(es).|
|PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 75,154 pass(es).|