Bug #105490
closed
TCA-driven SQL auto-generation should not fallback to varchar for "item-less" selectSingle fields (purely itemsProcFunc/FormDataprovider-filled)
0%
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.
Updated by Garvin Hicking 3 days ago
- Status changed from New to Needs Feedback
One can specify that in an extension's ext_tables.sql however. If we were to change this now, it would be a breaking change along with a needed deprecation in v14, so it wouldn't materialize before v15.
A data provider / itemsProcFunc could provide strings too, so I don't think having an INT would be the "proper" choice here?
Thus I think changing this to INT would break much easier for developers, and break the assumption to "playing things safe" like you mentioned (because integer values could be saved as strings, but not the other way round).
Updated by S P 3 days ago
One can specify that in an extension's ext_tables.sql however.
Yes, of course. I only question the default column type. TYPO3 currently assumes that "varchar" is a safe default type if none other information is present for a single select field. However on other occurances it assumes TEXT as safe (types category, slug, group or non-singleSelect select, for example). So this is already inconsistent to other fields (including select itself!). The question is: why do singleSelect fields fall back to varchar in the first place? Personally, I'd prefer INT UNSIGNED, but at least to be consistent with all other fields it should be TEXT.
Updated by Garvin Hicking 3 days ago
The reasoning is that select <option> fields rarely have big chunks of text in it? Varchars have index/storage advantages (with disadvantages too of course). This is a place where we can utilize it by "plausibility".
Updated by S P 3 days ago
Garvin Hicking wrote in #note-3:
The reasoning is that select <option> fields rarely have big chunks of text in it? Varchars have index/storage advantages (with disadvantages too of course). This is a place where we can utilize it by "plausibility".
I know all of this. But then I ask the other way round, why is the global fallback for non-singleSelect select fields TEXT and not varchar? :) Of course, it is TEXT because of long CSV values exceeding 255 chars. So we have the case that select fields can be "anything", decided by non-obvious column config combinations, see also: #105441 (where null alongside only-ints is casted to varchar instead of int).
Updated by S P 3 days ago
- Related to Bug #105441: Autogeneration of selectSingle with foreign_table and a custom item with value null tries to create a varchar field added
Updated by Garvin Hicking 3 days ago
I don't enjoy the tone of the conversation. I'm leaving it for others to decide.
Updated by Georg Ringer 3 days ago
- Status changed from Needs Feedback to Rejected
as there is a easy way to overrule the default field and changing the default is highly breaking I am closing this issue.
hope you understand
Updated by S P 3 days ago
Georg Ringer wrote in #note-7:
hope you understand
I don't really care, after all some colum type has to be the default. ;) I just found it inconsistent that a select field can have three different SQL column type defaults, depending on not-really-documented combinations of the config options of select fields (the 1200 lines switch in DefaultTcaSchema.php of ext:core is the "documentation"). I'd expected selectSingle to be either UNSIGEND INT (because it usually holds a uid) or TEXT (the same fallback as other select fields have) -- but instead there pops up a VARCHAR (even if no dbFieldLength is specified!), that's all I questioned/wondered.