2012-07-23 13 views
30

Desde mi mesa de crear un script, he definido el campo hasMultipleColors como BIT:MySQL valores siempre volviendo tan blanco

hasMultipleColors BIT NOT NULL, 

Cuando se ejecuta una instrucción INSERT, no hay advertencias lanzadas para esta o la otra BIT campos, pero la selección de las filas muestra que todos los valores BIT están en blanco.

tratando manualmente actualizar estos registros desde la línea de comandos da efecto extraño - muestra que el registro fue partido y cambió (en su caso), pero aún así siempre se muestra en blanco.

versión del servidor: 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) 

¿Alguna idea?

+1

¿Por qué no estás usando 'BOOL' en lugar de' BIT' para eso? De la semántica de su nombre de campo, tendría más sentido. – Romain

+2

Hice algunas lecturas con respecto a los tipos de datos BOOL frente a BIT frente a TINYINT, y lo que obtuve fue que MySQL maneja BOOL de una manera muy pobre, no portátil para otras soluciones RDBMS, por lo que generalmente es ideal para TINYINT o BIT (más eficiente). – CdrXndr

Respuesta

44

, es necesario especificar el campo de bits en un entero.

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

Esto es debido a un error, consulte: http://bugs.mysql.com/bug.php?id=43670. El estado dice: No arreglará.

+1

Entendido, gracias. Por lo tanto, este es solo un problema de visualización en lugar de datos capturados y almacenados correctamente.¿Hay alguna manera de lanzar automáticamente tipos de datos de bit cuando se usa un * en select? – CdrXndr

+1

Tengo una versión muy extraña de esto, donde en el primer caso, los campos BIT se muestran sin ningún problema. Pero luego en una tabla diferente, donde los campos BIT se definen como en la primera tabla, nada se imprime a menos que haga algo como agregar 0 a cada columna BIT. Si esto es un error, ¿por qué está funcionando en el primer caso pero no en el segundo? TL: DR para dar los detalles sangrientos. Otra rareza: mientras este problema ocurre en el cliente mysql en mi servidor, el cliente integrado en mi IDE (PHPStorm) no tiene el problema en absoluto, y simplemente trabaja con campos BIT. –

+0

@RTB hay una solución simple a este problema y lo agregué. –

0

La verdadera razón del efecto que ve es que se hace bien y como se esperaba.

El campo bit tiene bits y, por lo tanto, devuelve bits, e intentar generar un solo bit como carácter mostrará el carácter con el valor de bit dado, en este caso un carácter de control de ancho cero.

algunos programas pueden manejar esto automágicamente, pero para la línea de comandos de MySQL que tendrá que proyectarlo como int de alguna manera (por ejemplo, mediante la adición de cero).

En idiomas como PHP, el valor ordinal del carácter le dará el valor correcto, usando la función ord() (aunque para ser realmente correcto, debería convertirse de cadena decimal a binaria, para trabajar para campos de bit más largos) de un personaje).

EDIT:
encontrado una fuente bastante viejo diciendo que ha cambiado, por lo que una actualización de MySQL puede hacer que todo funcione como se esperaba más: http://gphemsley.wordpress.com/2010/02/08/php-mysql-and-the-bit-field-type/

2

Puede emitir campo de bits a firmar.

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

Se devolverá 1 o 0 basa en el valor de hasMultipleColors.

Cuestiones relacionadas