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

[Dmitry Dulepov [typo3]]

Martin Kutschker wrote:
> 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.

How do you know it is int? It is possible to use varchar even for maxitems=1 and prepend_tname=0.

> 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.

Ok, let's say, "empty value specified by user". Why do you change empty value to 0 then? ;) User did not insert anything, so you should not insert anything too!

> 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.

Then you have to generate uid values too. It is DB defaults as well.

I feel that sending huge amount of default zeros and empty strings is not actually a good solution. I'd prefer to send as less data as possible: smaller packets, better performance.

>> 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 ;-)

TYPO3 treats 0 as invalid pid in such cases, not like "no pid".

And yes, according to my taste it is wrong to store 0 on user behalf when he did not enter another value. 0 is not the logical default in this case. Logical default is empty value (whtever it looks like from DB point of view).

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

Why? Perfectly logical: empty provided by user -> empty send to database.

> 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

Ineffective :( int is better.

-- 
Dmitry Dulepov
TYPO3 core team
Learn more about TYPO3! Read http://typo3bloke.net/
Skype: callto:liels_bugs but go straight to business!