In Prague plach (discussion lead), yched, fago, berdir, amateescu and das-peter discussed "unified" field storage, see the notes here. I'm copying the relevant part of the notes here:
- Support field API storage for non-configurable fields brings terminology questions up. How is a field called that’s stored via the field API mechanism but not configurable in the field UI?
- We determined, in addition to field API, and base-table storage (both part of the storage controller), there is the case of fields being stored in a custom way by modules. That is, modules add the field via
hook_entity_field_info()and take care of storage theirselves.
- After some discussion we came up with the following solution/proposal.
We iterate over some keys in entity and field definition to clarify terminology + improve the storage controller to work based upon entity field definitions instead of field instances (see steps for details on that).
field uiflag determines on whether the Field UI is enabled. @yched pointed out this is not necessarily about configuring fields, but works for entities just having base fields but do not allow adding custom fields also. So it should be renamed, e.g. to
fieldablechanged as it does not refer to whether field API is supported by the entity type. What it means now, is whether the storage controller supports storing additional fields defined by modules. We agreed that there needs to be a flag in addition to the storage controller implementing the respective interface. The best name we came up for it is
extendable, as it indicates whether the entity storage supports adding fields -
configurable_fieldsis a new boolean flag and used by the Field module to know whether it should support the entity type and by Field UI to know whether it is allowed to add fields via the UI -
provider: this key is used to tell which module provides the field defintions; Configurable fields will have
field- so this can be used by the Field module to identify its fields. Then, this key allows us to identify base fields (=fields provided with the entity types) as they have a NULL values. Lastly, it’s something important to have in order to be able to track dependencies, e.g. when a module is configured to rely on a field to be there (a rule configuration needs it to run, a module uses a token of that field, ..) -
custom_storage: this indicates whether the storage controller should take care of storing the field values -
- The core SQL storage controller determines a list of fields to be stored in the base table (optimized) storage (single-cardinality base fields). Any other field, except custom storage fields, gets CCK tables.
- This optimization is something internal to the storage controller, so the method is not on an interface.
- A MongoDB storage controller would just store every field not having with custom storage enabled, as it does not have to do any special optimizations.
this depends on the implementation of class based field definitions for entity fields, so the issue is a prerequesite. move the
Interfaceto work with Field definitionn (this issue):
+ adapt the code in the method implementations (probably means adding missing methods in
- field purging: we need to abstract the current “storage of deleted field / instance definitions in State()” to “register some
FieldDefinitionInterfacefor purging” (stored in State() too, but needs to store
<code>FieldDefinitionInterfaceobjects istead of CMI data. (follow-up)
fieldableis renamed, we’ll have to rename the
FieldableStorageControllerBase // Interfaceaccordingly to
The goals of this issue are to
- have FieldableEntityStorageInterface be decoupled from configurable field interfaces, i.e. use entity field interfaces only
- clean FieldableEntityStorageInterface up, such that it is a good API that modules can use for notifying the entity storage of changes to field definitions in general (for base fields as well)
- Get reviews & address them
- Added getBundle() to FieldDefinitionInterface and getUniqueStorageIdentifier() to FieldStorageDefinitionInterface
- (Undocumented) support for running queries on deleted fields via Entity Query is gone
- Removed FieldConfig::entityCount() and replaced it by countFieldData() on the storage. One can still count entities using entity query, but not by using deleted fields.
- Added purgeFieldData(), countFieldData() and finalizePurge() to FieldableEntityStorageInterface and respective base classes + clarified docs.
- FieldableEntityStorageInterface has been improved to go with EntityFieldQuery terminology - those methods have been used by field.module only so far though
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,790 pass(es). View
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,882 pass(es). View
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch 2144263.127.patch. Unable to apply patch. See the log in the details link for more information. View