MySQL: errore 1067 Invalid default value

Perché STRICT_TRANS_TABLES e NO_ZERO_DATE sono attivi di default nelle versioni nuove.

ERROR 1067 (42000): Invalid default value for …

Il server rifiuta il default di una colonna: non è valido per il tipo o viola il sql_mode attivo, per esempio una data zero con NO_ZERO_DATE.

daniele@mikweb: ~/errors — less mysql-1067-invalid-default-value.md

Come appare il messaggio

ERROR 1067 (42000): Invalid default value for 'created_at'

Una colonna TIMESTAMP o DATETIME ha come default '0000-00-00 00:00:00' mentre NO_ZERO_DATE è attivo.
Il dump viene da MySQL 5.6 e usa default che 5.7/8.0 rifiutano con STRICT_TRANS_TABLES.
Il default non corrisponde al tipo: testo su una colonna numerica, o un default su TEXT prima di MySQL 8.0.13.
Charset o collation del default non corrispondono alla colonna, frequente nei dump vecchi.
Una migrazione mette CURRENT_TIMESTAMP su una colonna che in questa versione non lo consente.

Mostra il sql_mode attivo
mysql -e "SELECT @@sql_mode;"
Controlla la definizione della colonna
mysqldump --no-data db table | grep -i -A3 -E 'timestamp|datetime'
Confronta versione di origine e destinazione
mysql --version; grep -i -m1 'server version' dump.sql

Allinea il default al tipo: DEFAULT CURRENT_TIMESTAMP invece di una data zero, oppure permetti NULL.
Per un import allenta il modo solo per la sessione: SET SESSION sql_mode='NO_ENGINE_SUBSTITUTION'; – in modo consapevole e non permanente.
Meglio testare il dump sulla versione di destinazione e rigenerarlo con le opzioni giuste, invece di forzare il modo.
Ricontrolla sql_mode dopo l'import, altrimenti entrano date zero senza accorgersene.

Perché STRICT_TRANS_TABLES e NO_ZERO_DATE sono attivi di default nelle versioni nuove.

Tecnicamente sì, ma il database salverebbe valori sbagliati in silenzio. Ha senso solo durante un import.