2014-06-13 16 views
10

Ho una tabella MySQL con un campo definito come:data/ora NOT NULL DEFAULT CURRENT_TIMESTAMP può essere nullo su una macchina ma non un'altra?

`created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP 

sulla mia macchina locale, posso correre:

INSERT INTO mytbl (id, user_id, created) VALUES(88882341234, 765, null); 
SELECT id, user_id, created FROM mytbl WHERE id = '88882341234'; 

E poi 'creato' visualizzerà qualcosa come '2014-06- 13 21:16:42 '.

Ma sul mio server di gestione temporanea, se corro le stesse query, ottengo questo errore:

Column 'created' cannot be null. 

Gli schemi delle tabelle sono le stesse (tra locale e messa in scena), che ho assicurato tramite mysqldump (clonare la tabella prima di eseguire questo test).

Sto eseguendo MySql 5.6.17 su entrambe le macchine. Ho anche assicurato che entrambi abbiano lo stesso sql_mode.

Quale potrebbe essere il problema?

P.S. Per le persone che non sanno perché sarei impostazione del valore di un campo non annullabile a null, MySql Docs dicono:

In addition, you can initialize or update any TIMESTAMP column to the current date and time by assigning it a NULL value, unless it has been defined with the NULL attribute to permit NULL values.

+0

Il problema potrebbe essere che la query è semplicemente sbagliato e MySql sta tenendo la mano sulla macchina locale (Sospetto a causa della diversa modalità SQL in vigore). Se 'created' non può essere' null', allora perché stai cercando di impostarlo su 'null'? – Jon

+0

Penso che questo affermi che l'impostazione di un valore del campo di timestamp non annullabile su null sia un modo per impostarlo automaticamente come l'ora corrente: http://dev.mysql.com/doc/refman/5.5/en/ timestamp-initialization.html Quindi chiunque abbia scritto questa query originariamente (non io) probabilmente lo intendeva. Cosa intendi per "modalità SQL diversa"? Come posso verificarlo e modificarlo? – Ryan

+0

Scommetto che intendi http://dev.mysql.com/doc/refman/5.6/en/sql-mode.html. Indagherò – Ryan

risposta

26

ho trovato quale fosse il problema. La variabile/parametro MySql explicit_defaults_for_timestamp era OFF sulla mia macchina locale ma ON sulla mia macchina remota.

Ho visitato la mia pagina AWS RDS Gruppi di parametri e cambiato explicit_defaults_for_timestamp da 1 a 0. Poi sono andato alla mia pagina istanze AWS RDS per guardare quando "Gruppo di parametri" cambiato da "Applicazione" a "in attesa-reboot". Quindi ho riavviato l'istanza particolare.

Questi link mi ha aiutato:

+0

Grazie, lavora per me nel mio server di Ubuntu con mysql 5.6. – VictorV

+1

Grazie per aver pubblicato l'aggiornamento. Probabilmente ci avresti impiegato anni per trovare il problema! – Andris

+0

Ha funzionato per me quando mi sono trasferito dal tradizionale server mySQL ad Amazon RDS. –

0

Il problema principale è che il INSERT è proprio sbagliato: si sta cercando di inserire un NULL in una colonna non annullabile.

Che cosa si dovrebbe fare è semplicemente fissare la query:

INSERT INTO mytbl (id, user_id) VALUES(88882341234, 765); 

Il motivo di questa causa un errore solo sul server di gestione temporanea è che il server opera in strict SQL mode e quindi immediatamente interrompe quando si tenta di inserire un valore errato in created.

È possibile controllare facilmente la modalità di SQL in vigore con SELECT @@SESSION.sql_mode e modificarlo (forse in modo da poter riprodurre l'errore sul proprio server) con

SET SESSION sql_mode = 'STRICT_ALL_TABLES' 
+0

Sfortunatamente, i miei 2 server hanno già la stessa sql_mode, quindi questo non è il problema. E non voglio modificare la query perché ha funzionato per anni (e sta ancora lavorando sul mio computer locale) e ha smesso di funzionare sul mio server di Staging questa settimana improvvisamente (e non sono stato in grado di capire cosa * cambiato * con il mio server di gestione temporanea). Grazie per aver provato, però. – Ryan

+0

@Ryan: Che importa se ha funzionato per anni se non funziona ora e sai che è sbagliato? Cosa ci vorrebbe per decidere che i bisogni irrisolti vengano risolti? È il tuo codice, la tua scelta di sicuro, ma non riesco a ingannare questa linea di ragionamento. – Jon

+2

Il fatto che sia * non * rotto sulla mia macchina locale o in produzione significa che non ho ancora capito il problema, e il problema è specifico di Staging. Non voglio mai cambiare codice (specialmente quando per noi sta facendo soldi in produzione) senza capire. Voglio capire cosa è cambiato negli ultimi giorni. – Ryan

Problemi correlati