Dmitry Lenev wrote:
> Hello, Martin!
>
> * Martin Hansson <martin.hansson@stripped> [11/03/24 12:29]:
>
>> #At file:///data0/martin/bzrroot/bug11746628/t-enginestuff/ based on
> revid:tor.didriksen@stripped
>>
>> 3318 Martin Hansson 2011-03-24
>> Preliminary refactoring in order to fix Bug 11746628 -
>> 27645: DATETIME FIELD DOES NOT ACCEPT DEFAULT NOW()
>>
>> This patch removes all references to the members
>> TABLE::timestamp_field and TABLE::timestamp_field_type from
>> the handler API, as these are subject to removal in the fix
>> for the bug. Instead a new interface
>> TABLE::[begin|end][insert|update]() has been introduced. The
>> new member functions are called from the handler class as
>> opposed to copy-pasting the code in all handler subclasses,
>> as was the case previously.
>>
>
> Why do the code setting default value for columns with DEFAULT
> NOW() clause has to be called from the handler class at all?
>
It doesn't :-)
Look, you're commenting on a patch that is nearly one month old. This
has been completely re-designed and reimplemented several times already.
> I know that it works this way now, but, IMO, this is rather a bug than
> a feature. Particularly, this means that correct default values for
> such columns are not accessible from BEFORE INSERT trigger as they
> should be per SQL standard.
>
Hmm...this area is not my expertise. I will look into this for sure.
> I think that rather than following old approach and making code that
> implements it more generic/nicer we should bite the bullet now and
> move this code/call to it out of handler, completely, to the different
> stage of row processing for INSERT, to some point before execution of
> BEFORE INSERT triggers.
>
I am doing exactly that. I'm happy to see that others have come to the
same conclusion. :-)
> I will be happy to provide any assistance with this if needed!
>
>
Great to have you on board, Dmitry!
Best Regards
Martin
