Implement a sane storage default mapping [#1936382]

Problem/Motivation

DatabaseStorageControllerNG accesses field properties hardcoded in following methods:

DatabaseStorageControllerNG::mapToDataStorageRecord()
DatabaseStorageControllerNG::mapToRevisionStorageRecord()
DatabaseStorageControllerNG::mapToStorageRecord()
DatabaseStorageControllerNG::attachPropertyData()

In all this locations ->value is used to either read or write a field property.
This is ugly because there's no rule that defines that a field has to have a value field property.
E.g. EntityReferenceItem defines target_id and entity as properties.
Thus EntityReferenceItem has some mapping in its getter / setter methods to deal with value.
However, we really should provide a sane way to define what properties have to be handled by the storage controler.
Open question: Is there the posibility that e.g. EntityReferenceItem can define more than one property to be stored / read?

"Related Issues":

Proposed resolution

Remaining tasks

User interface changes

API changes

Comments

Comment #1

das-peter commented 7 March 2013 at 15:06

Component:

simpletest.module

» field system

"field system" I guess.

Comment #2

fago

German

Vienna

commented 9 March 2013 at 11:55

Open question: Is there the posibility that e.g. EntityReferenceItem can define more than one property to be stored / read?

Sure, no one says there is just one property that should be stored. We should assume that every property that is not marked as 'computed' should be stored/loaded.

I'd suggest we come up with a simple default-mapping routine of field+field item property names to database tables + columns.

Let me try:

Identifying database tables:
if field is translatable and revisionable -> data table
if field is not translatable and revisionable -> base table
(other combinations of translatable and revisionable are not supported by default)

Identifying columns:
A field with name $field_name and multiple field item properties $value1 and $value2 would load/store to "{$field_name}__{$value1}" and "{$field_name}__{$value2}".
A field with name $field_name and a single field item property $value1 would load/store to "{$field_name}".

Possible conflicts:
Yes, this pattern might end up with conflicts if a field is called "name__value". But this mapping only applies to pre-defined base fields and it's just part of the default-database controller. For this controller we can clearly document that it is not capable of working with pre-defined fields with two underscores. If you want to do that, override it or write your own storage controller.
So we'd have a restriction of not allowing two underscores in a row for our default controller, while the API in general does not have this restriction. I think that's reasonable and gives us a simple way to map things.

Thoughts?