Project

General

Profile

Actions

Bug #105490

closed

TCA-driven SQL auto-generation should not fallback to varchar for "item-less" selectSingle fields (purely itemsProcFunc/FormDataprovider-filled)

Added by S P 3 days ago. Updated 3 days ago.

Status:
Rejected
Priority:
Should have
Assignee:
-
Category:
Database API (Doctrine DBAL)
Target version:
-
Start date:
2024-10-28
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
13
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

The global fallback for singleSelect fields is currently a varchar(255). On some projects we have single selects which are filled solely by a FormDataProvider or via an itemsProcFunc. For these I have to do this hack to get an int field if I'd like to use SQL auto generation:

'config' => [
    'type' => 'select',
    'renderType' => 'selectSingle',
    'items' => [
        [
            'label' => 'dummy-for-sql-generation|array-filled-by-form-data-provider',
            'value' => 0,
        ],
    ],
],

IMHO, singleSelect fields with neither predefined items nor foreignTable should be INT UNSIGNED as fallback. Or at least there should be a TCA option to define a SQL column type directly in TCA (like dbColumnType, like there is for the dbFieldLength already).

I assume the varchar fallback is there "to be safe" (no accidental data truncating on v13 upgrade), but checking the column defintions is up to the upgrading developer anyway when he deletes the ext_tables.sql lines. Someone who is cabable of custom-filling an entire select field should also be able to check the SQL column type on an upgrade.


Related issues 1 (1 open0 closed)

Related to TYPO3 Core - Bug #105441: Autogeneration of selectSingle with foreign_table and a custom item with value null tries to create a varchar fieldNew2024-10-24

Actions
Actions

Also available in: Atom PDF