Support custom one to many relations in yaml fixtures by nesting entities key

[nmaier95]

Does your feature request relate to a problem?

Currently when writing yaml fixtures for test cases it is possible to model a datastructure by using the entities key. However the relation only correctly resolves when depending on the default pid column (e.g. content elements inside pages, see "example 1").

Example 1

entitySettings:
    '*':
        nodeColumnName: 'pid'
        columnNames: {id: 'uid', language: 'sys_language_uid'}
        defaultValues: {pid: 0}
    page:
        isNode: true
        tableName: 'pages'
        languageColumnNames: ['l10n_parent', 'l10n_source']
        defaultValues: {hidden: 0, doktype: 1}
    content:
        tableName: 'tt_content'
        languageColumnNames: ['l18n_parent', 'l10n_source']

entities:
    page:
        - self: {pid: 1, title: 'Sample Page'}
          entities:
              content:
                  - self: {CType: 'textmedia', header: 'Sample Content'}

Custom data structures with their own arbitrary relations cannot be modeled. Besides by creating them by their own and writing their incremented Uids (see inline_record: 10000 at "example 2") by hand into the relation column which gets very messy when handling many.

Example 2

__variables:
    - &pageStandard 1
    - &siteId 1

entitySettings:
    '*':
        nodeColumnName: 'pid'
        defaultValues: { pid: 0 }
    page:
        isNode: true
        tableName: 'pages'
        parentColumnName: 'pid'
        languageColumnNames: [ 'l10n_parent', 'l10n_source' ]
        columnNames: { type: 'doktype' }
        defaultValues: { hidden: 0, doktype: *pageStandard }
    productDetail:
        isNode: true
        tableName: 'tx_extname_domain_model_productdetail'
        languageColumnNames: [ 'l18n_parent', 'l10n_source' ]
        defaultValues:
            hidden: 0
    productPackageSize:
        tableName: 'tx_extname_domain_model_packagesize'
        languageColumnNames: [ 'l18n_parent', 'l10n_source' ]
        defaultValues:
            hidden: 0

entities:
    page:
        -   self: { pid: *siteId, title: 'Product Page A', type: 103, backendLayout: 'pagets__productPage', inline_record: 10000}
            entities:
                productDetail:
                    -   self: { title: 'Product A' }
                        entities:
                            productPackageSize:
                                -   self:
                                        title: 'Size A'
                                        size: 1
                                -   self:
                                        title: 'Size B'
                                        size: 2

Now lets assume one product may have many packageSizes (like also shown in "example 2"). And the TCA for the relation is configured as followed:

tx_extname_domain_model_productdetail

[...]
'package_sizes' => [
    'label' => 'Package Sizes',
    'config' => [
        'type' => 'inline',
        'foreign_table' => 'tx_extname_domain_model_packagesize',
        'foreign_field' => 'package_size',
        'minitems' => 0,
        'maxitems' => 10,
    ],
],
[...]

tx_extname_domain_model_packagesize

[...]
'product_detail' => [
    'config' => [
        'type' => 'passthrough',
    ],
],
[...]

So each packageSize has the uid of its productDetail set in its column product_detail.

Now to the root cause: The TYPO3\CMS\Core\DataHandling\DataHandler needs these kind of relations to be resolved by having the relation set the other way around. Meaning the datastructure the DataHandler expects needs to be like this:

$data = [
    [...]
    'tx_extname_domain_model_productdetail' => [
        'NEW123456789' => [
            [...]
            'title' => 'Product A',
            'package_sizes' => 'NEW123,NEW321'
        ]
    ],
    'tx_extname_domain_model_packagesize' => [
        'NEW123' => [
            [...]
            'title' => 'Size A',
            'size' => 1
        ],
        'NEW321' => [
            [...]
            'title' => 'Size B',
            'size' => 2
        ]
    ]
];

Where the relation is set on the parent record and not like how it is stored in reality: on the child record.

Preferred Solution

Being able to configure those kind of relations by setting some sort of "parent relation column" in addition to the "pid" inside of the entitySettings of each fixture yaml.