2012-07-23 13 views
30

Dal mio script create table, ho definito il campo hasMultipleColors come un po ':MySQL valori sempre tornare altrettanto vuote

hasMultipleColors BIT NOT NULL, 

Quando si esegue un INSERT, non ci sono avvertimenti lanciati per questa o l'altra BIT campi, ma selezionando le righe viene mostrato che tutti i valori BIT sono vuoti.

Cercare manualmente di AGGIORNARE questi record dalla riga di comando dà un effetto strano: mostra che il record è stato abbinato e modificato (se appropriato), ma rimane sempre vuoto.

versione Server: 5.5.24-0ubuntu0.12.04.1 (Ubuntu)

mysql> update pumps set hasMultipleColors = 1 where id = 1; 
Query OK, 0 rows affected (0.00 sec) 
Rows matched: 1 Changed: 0 Warnings: 0 

mysql> select hasMultipleColors from pumps where id = 1; 
+-------------------+ 
| hasMultipleColors | 
+-------------------+ 
|     | 
+-------------------+ 
1 row in set (0.00 sec) 

mysql> update pumps set hasMultipleColors = b'0' where id = 1; 
Query OK, 1 row affected (0.00 sec) 
Rows matched: 1 Changed: 1 Warnings: 0 

mysql> select hasMultipleColors from pumps where id = 1; 
+-------------------+ 
| hasMultipleColors | 
+-------------------+ 
|     | 
+-------------------+ 
1 row in set (0.00 sec) 

Qualche idea?

+1

Perché non stai usando 'BOOL' invece di' BIT' per quello? Dalla semantica del nome del tuo campo, avrebbe più senso. – Romain

+2

Ho fatto alcune letture riguardo i tipi di dati BOOL vs. BIT vs. TINYINT, e il take-away che ho preso è stato che MySQL gestisce BOOL in modo molto povero - non portabile ad altre soluzioni RDBMS - quindi è generalmente ideale andare con TINYINT o BIT (più efficiente). – CdrXndr

risposta

44

È necessario lanciare il campo di bit in un intero.

mysql> select hasMultipleColors+0 from pumps where id = 1; 

Questo è causa di un bug, vedi: http://bugs.mysql.com/bug.php?id=43670. Lo stato dice: non risolverà.

+1

Capito, grazie. Quindi questo è solo un problema di visualizzazione piuttosto che i dati vengono acquisiti e archiviati correttamente.Qualche modo per lanciare automaticamente i tipi di dati bit quando si utilizza un * in select? – CdrXndr

+1

Ho una versione molto strana di questo, dove nel primo caso, i campi BIT vengono visualizzati senza problemi. Ma poi in una tabella diversa, dove i campi BIT sono definiti come nella prima tabella, non viene stampato nulla a meno che non faccia qualcosa come aggiungere 0 a ciascuna colonna BIT. Se questo è un bug, allora perché funziona solo nel primo caso ma non nel secondo? TL: DR per dare i dettagli cruenti. Un'altra stranezza: mentre questo problema si verifica nel client mysql sul mio server, il client integrato nel mio IDE (PHPStorm) non ha il problema e funziona solo con i campi BIT. –

+0

@RTB c'è una soluzione semplice a questo problema e l'ho aggiunto. –

0

Il vero motivo dell'effetto che si vede è che è stato fatto correttamente e come previsto.

Il campo bit ha bit e quindi restituisce bit, e cercando di emettere un singolo bit come carattere mostrerà il carattere con il valore di bit dato - in questo caso un carattere di controllo a larghezza zero.

Alcuni software possono gestirlo automagicamente, ma per la riga di comando MySQL dovrete eseguire il cast come int in qualche modo (ad esempio aggiungendo zero).

In lingue come PHP il valore ordinale del carattere ti darà il giusto valore, usando la funzione ord() (anche se per essere veramente corretto, dovrebbe essere convertito da stringa decimale a stringa binaria, per lavorare per campi di bit più lunghi di un personaggio).

EDIT:
trovato una fonte abbastanza vecchio detto che ha cambiato, in modo da un aggiornamento di MySQL potrebbe far funzionare tutto più come previsto: http://gphemsley.wordpress.com/2010/02/08/php-mysql-and-the-bit-field-type/

2

È possibile lanciare campo BIT a segno.

SELECT CAST(hasMultipleColors AS UNSIGNED) AS hasMultipleColors from pumps where id = 1 

Rinvierà riferiscono 1 o 0 sul valore di hasMultipleColors.

Problemi correlati