Affects Version/s: None
Sprint:Stetind Sprint 1, Stetind Sprint 2, Stetind Sprint 3, Stetind Sprint 4, Stetind Sprint 5, Stetind Sprint 6
Currently the storage and update of content preserves a big lack of the legacy kernel - that is redundant storage of fields in the dimensions language and version. Recall that the current kernel has a worst case of (n/2*l)+v*n fields where n is the amount of fields in the content type, l the amount of languages and v the amount of versions. Example worst case:
99 non translatable attributes, one translatable attribute, 10 languages.
Assuming to make for each translation one version - if the one translatable attribute is translated 10 times we have
10 versions. So we have
100 + 200 + 300 ... + 1000 = 5500 Fields. That are 5390 redundant fields.
For each additional version we may get 999 more redundant fields.
As this is one main reason for the lack of scalability storage engines may not want to do this in this way. But now they are kind of forced as
the BL passes for each field definition values down - if set or not by the user. Note that the BL passes also copies from attributes which are not set by the user on update. And the current storage engine stores what it gets.
The iteration over the field definitions must be done in the legacy storage engine and the BL only passes values which are set and does not make a fallback to the $fieldType->getEmptyValue on create and does not pass the old value on update (if not changed).
The would enable other engines to avoid redundant storage.
Note: Above the public API or in BL there still can be methods, which fill a content not containing all values with empty values if needed.