[TYPO3-core] RFC #8542: Cannot create page with Mysl in strict mode (STRICT_TRANS_TABLES)

[Martin Kutschker]

Dmitry Dulepov [typo3] schrieb:
> Hi Masi!
> 
> Martin Kutschker wrote:
>> Dmitry Dulepov [typo3] schrieb:
>>> What about unsetting empty values in TCEmain? Leave it to MySQL to 
>>> decide what to put by default.
>>
>> Hm, probably possible, but not logical. Because some value has to be 
>> set when you safe a TCE form that has been displayed. The error occurs 
>> when you want eg to save a new page. Then the incoming value is an 
>> empty string (because the field has been displayed) and not a 0 *. 
>> Also I'm not happy with unsetting values in the middle of the processing.
> 
> I think it is perfectly ok to unset it. It means it will not go to 
> database, that's all. Now we send '', which is plain wrong in many 
> cases. Sending '0' is wrong for varchar fields.

But we do make an update! And who says it's a VARCHAR? The field in 
question is an INT, that's why we have the problem.

> And we cannot guess what 
> we truly should send because docs do not say when int or varchar is 
> used. So unsetting value (as if it is not provided) looks most logical 
> to me. In fact, it is not provided by user! So should not be set in db 
> call. What do you think?

You're wrong when you saye that the value is not provided by the user. 
It is, because he does so, when he clicks on the save button of TCE 
forms. He only chose to save an "empty" value for the storage pid.

> Well, it does not requires it. That's the problem.

I disagree. I don't want to rely on DB defaults if I really supply a 
value. And this is what we do, when we come from a TCE form.

>> * So there is one more solution. Change TCE forms in such a way it 
>> uses 0 as value for initial display.
> 
> It does not prevent 0 in varchar field...

Which is no problem at all because TYPO3 (for this kind of TCA field) 
treats a single 0 as no pid. There is absolutely nothing IMHO which 
speak against storing '0' in a VARCHAR than your taste ;-)

So I really would like to modify the value rather than unset it. 
Unsetting it seems to me an unclean solution in this context.

This has the nice benefit that "type"="group" / "internal_type"=db / 
"MM"= / "maxitems"=1 / "prepend_tname"=0 will work for INT and VARCHAR 
fields, so extension authors don't have to worry.

Mind that only MM fields must be, according to the docs, an INT. Other 
types should probably be VARCHARs, but alas in the Core it is different.

If you like we can change pages/storage_pid to VARCHAR for 4.3 and make 
the patch a temporary solution for 4.2.x

Masi