When using TCA select multiple => 1 only one item is available in fluid

Question

im using a select in my TCA for my items table with the option "multiple" activated so that i can select the same item multiple times:

'config' => [
            'type' => 'select',
            'renderType' => 'selectMultipleSideBySide',
            'foreign_table' => 'tx_extension_domain_model_item',
            'default' => 0,
            'size' => 10,
            'multiple' => 1,
            'autoSizeMax' => 30,
            'maxitems' => 9999,
            'fieldControl' => [
                'editPopup' => [
                    'disabled' => false,
                ],
                'addRecord' => [
                    'disabled' => false,
                ],
                'listModule' => [
                    'disabled' => true,
                ],
            ],
        ],

That works pretty well and is saved correctly in the db like 1,1,2,2,3,3,4,4. But Fluid outputs only the items 1,2,3,4. It seems that the multiple Items are filtered by default. Is there any option to disable this filter thingy?

Answer 1

Although I'm not entirely sure about the cause, the described use case does indicate that perhaps an improved structure is the right solution. Rather than selecting a product X number of times to indicate "used X times", and allowing this value to be stored as CSV in database, I would suggest:

• Adding an intermediate entity, for example called ProductUsage
• Construct the entity model for ProductUsage to contain a count field, e.g. used_count
• And make it contain two 1:1 relation fields, one for parent_product and one for child_product
• Relate Product model to ProductUsage in two ways:
  • From parent product, Product->uses can contain a list of ProductUsage instances where product is the parent_product
  • From child product, Product->usedBy can contain a list of ProductUsage instances where product is the child_product

This structure also has the benefit that you can later elaborate on how product A "uses" product B (consists of, requires, connects to, supports, etc.) by expressing the type of usage as a property on the ProductUsage object. It also means you can later connect products with different "types" of usages (product A "connects to" 3 of product B and "requires" 1 of product B). And so on, with increasing degree of specificity for what the "usage" actually is.

And you can select all ProductUsage records to express a relation graph (diagram of how all your products are connected).

But more importantly, it is a standardised form of relation instead of having a CSV value which allows duplicates, and it's SQL friendly by allowing you to select the key values (number of usages) with a JOIN query.