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

das-peter’s picture

Component:simpletest.module» field system

"field system" I guess.

fago’s picture

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?

amateescu’s picture

For this controller we can clearly document that it is not capable of working with pre-defined fields with two underscores.

I'd go one step further and throw an exception when the field is created in this case. Other than that, the suggestion sounds sane.

das-peter’s picture

... the suggestion sounds sane.

Agreed.
I'd like to start working on this or is there anyone else who wants to take it?

sun’s picture

Status:Active» Closed (duplicate)

Please correct me if I'm wrong, but I believe that this issue is obsolete by now. (?)

amateescu’s picture