osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: explicit_defaults_for_timestamp for mysql


This sounds sensible and would mean we could also run on GCP's MySQL offering too.

This would need someone to try out and check that timezones behave sensibly with this change made.

Any volunteers?

-ash

> On 19 Oct 2018, at 17:32, Deng Xiaodong <xd.deng.r@xxxxxxxxx> wrote:
> 
> Wondering if there is any further thoughts about this proposal kindly raised by Feng Lu earlier?
> 
> If we can skip this check & allow explicit_defaults_for_timestamp to be 0, it would be helpful, especially for enterprise users in whose environments it’s really hard to ask for a database global variable change (like myself…).
> 
> 
> XD
> 
> On 2018/08/28 15:23:10, Feng Lu <f...@xxxxxxxxxx.INVALID> wrote: 
>> Bolke, a gentle ping..> 
>> Thank you.> 
>> 
>> On Thu, Aug 23, 2018, 23:01 Feng Lu <fe...@xxxxxxxxxx> wrote:> 
>> 
>>> Hi all,> 
>>>> 
>>> After reading the MySQL documentation on the> 
>>> exlicit_defaults_for_timestamp, it appears that we can skip the check on explicit_defaults_for_timestamp> 
>>> = 1> 
>>> <https://github.com/apache/incubator-airflow/blob/master/airflow/migrations/versions/0e2a74e0fc9f_add_time_zone_awareness.py#L43> by> 
>>> setting the column to accept NULL explicitly. For example:> 
>>>> 
>>> op.alter_column(table_name='chart', column_name='last_modified',> 
>>> type_=mysql.TIMESTAMP(fsp=6)) -->> 
>>> op.alter_column(table_name='chart', column_name='last_modified',> 
>>> type_=mysql.TIMESTAMP(fsp=6), nullable=True)> 
>>>> 
>>> Here's why:> 
>>> From MySQL doc (when explicit_defaults_for_timestamp is set to True):> 
>>> "TIMESTAMP columns not explicitly declared with the NOT NULL attribute are> 
>>> automatically declared with the NULL attribute and permit NULL values.> 
>>> Assigning such a column a value of NULL sets it to NULL, not the current> 
>>> timestamp."> 
>>>> 
>>> Thanks and happy to shoot a PR if it makes sense.> 
>>>> 
>>> Feng> 
>>>> 
>>>> 
>>>>