From: Martin Hansson
Date: April 18 2011 1:56pm
Subject: Re: bzr commit into mysql-trunk branch (martin.hansson:3318)
List-Archive: http://lists.mysql.com/commits/135642
Message-Id: <4DAC4314.5060902@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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