Mini-Bug en MySQL

Iniciado por ^Tifa^, 4 Enero 2010, 22:42 PM

0 Miembros y 1 Visitante están viendo este tema.

^Tifa^

Puesto que reporte esto al bug tracking tool de MySQL y ellos hicieron caso omiso, diciendome que el tipo BINARY leia binarios no caracteres y cerraron el tema (Esto yo ya lo sabia), cuando les pregunte otra cosa  :xD  quiero advertir a todos los que alguna vez quieran usar tipo de datos BINARY en sus tablas.

Tengo este escenario de ejemplo:

Código (sql) [Seleccionar]


mysql> create table ejemplo(
    -> nombres binary(20));
Query OK, 0 rows affected (0.39 sec)

mysql> insert into ejemplo values('Juan'),('Pepe'),('Jose');
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> select * from ejemplo;
+----------------------+
| nombres              |
+----------------------+
| Juan                 |
| Pepe                 |
| Jose                 |
+----------------------+
3 rows in set (0.00 sec)


Hasta ahi como pueden ver todo funciona perfectamente bien  :D  ahora que ocurre si se quiere actualizar o eliminar algun dato, observen:

Código (sql) [Seleccionar]


mysql> update ejemplo set nombres = 'Carlos' where nombres = hex('Juan');
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0

mysql> update ejemplo set nombres = 'Carlos' where nombres = 'Juan';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0

mysql> delete from ejemplo where nombres = 'Pepe';
Query OK, 0 rows affected (0.00 sec)

mysql> select * from ejemplo;
+----------------------+
| nombres              |
+----------------------+
| Juan                 |
| Pepe                 |
| Jose                 |
+----------------------+
3 rows in set (0.00 sec)


Un poco chungo no??? no elimino, ni actualizo nada... (Utilize la funcion HEX por recomendacion de la gente de MySQL ya que ellos decian que usase esta funcion para actualizar los datos y cerraron el reporte del bug, pero obviamente No funciona como pueden ver).

Ahora se que muchos diran ese problema se resuelve con un simple ALTER si claro, observen:

Código (sql) [Seleccionar]


mysql> describe ejemplo;
+---------+------------+------+-----+---------+-------+
| Field   | Type       | Null | Key | Default | Extra |
+---------+------------+------+-----+---------+-------+
| nombres | binary(20) | YES  |     | NULL    |       |
+---------+------------+------+-----+---------+-------+
1 row in set (0.00 sec)

mysql> alter table ejemplo modify nombres varchar(25);
Query OK, 3 rows affected (0.45 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> update ejemplo set nombres = 'Carlos' where nombres = 'Juan';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0

mysql> delete from ejemplo where nombres = 'Pepe';
Query OK, 0 rows affected (0.00 sec)

mysql> select * from ejemplo;
+----------------------+
| nombres              |
+----------------------+
| Juan                 |
| Pepe                 |
| Jose                 |
+----------------------+
3 rows in set (0.00 sec)


Agur... no funciona. He reiniciado el servidor MySQL he reiniciado mi PC, he vuelto a ingresar al motor despues de reiniciado todo he intentado nuevamente lo anterior expuesto y NADA sigue sin Eliminar o Actualizar ningun dato.

Este problemita aplica tambien para tablas con otro tipo de dato (CHAR, VARCHAR, etc) y le cambies dicho campo a BINARY con ALTER, por ejemplo:

Código (sql) [Seleccionar]


mysql> create table ejemplo2(
    -> nombres varchar(20));
Query OK, 0 rows affected (0.38 sec)

mysql> insert into ejemplo2 values('pepe'),('Juan'),('pedro'),('luis');
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> select * from ejemplo2;
+---------+
| nombres |
+---------+
| pepe    |
| Juan    |
| pedro   |
| luis    |
+---------+
4 rows in set (0.00 sec)




Hasta ahi todo bien... de hecho puedo borrar o actualizar con el tipo de datos VARCHAR:

Código (sql) [Seleccionar]


mysql> update ejemplo2 set nombres = 'Cucu' where nombres = 'pepe';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from ejemplo2;
+---------+
| nombres |
+---------+
| Cucu    |
| Juan    |
| pedro   |
| luis    |
+---------+
4 rows in set (0.00 sec)




Hasta ahi todo bien ahora miren esto:

Código (sql) [Seleccionar]


mysql> alter table ejemplo2 modify nombres binary(20);
Query OK, 4 rows affected (0.27 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> select * from ejemplo2;
+----------------------+
| nombres              |
+----------------------+
| Cucu                 |
| Juan                 |
| pedro                |
| luis                 |
+----------------------+
4 rows in set (0.00 sec)

mysql> update ejemplo2 set nombres = 'Marta' where nombres = 'Cucu';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0




No actualizo el dato tampoco borra para el que quiera intentarlo, ahora hago nuevamente ALTER para que mi tipo de dato sea otra vez VARCHAR pensando vagamente que esto resolvera este problema:

Código (sql) [Seleccionar]


mysql> alter table ejemplo2 modify nombres varchar(20);
Query OK, 4 rows affected (0.10 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> describe ejemplo2;
+---------+-------------+------+-----+---------+-------+
| Field   | Type        | Null | Key | Default | Extra |
+---------+-------------+------+-----+---------+-------+
| nombres | varchar(20) | YES  |     | NULL    |       |
+---------+-------------+------+-----+---------+-------+
1 row in set (0.00 sec)

mysql> update ejemplo2 set nombres = 'Marta' where nombres = 'Cucu';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0




Como pueden ver en el campo Changed:0 indica que no actualizo los datos aun siendo VARCHAR  :-\  tampoco elimina los datos siempre y cuando usemos constantes digase campo = algo

Reiniciar el motor MySQL no resuelve este problema, tampoco reiniciar el servidor como tal.

Porque coloco esto aqui? por el simple hecho de que si alguien tuviera un foro como este, con tablas llenas de datos millones de ellos, y alguien de alguna manera hackea la DB y hace un ALTER y coloca campo BINARY y luego un ALTER para retornar a VARCHAR y digamos que ese campo donde se aplico eso, es el campo Mensajes (POST) del foro, y luego ese usuario se antoja de entrar al foro y insultar , ofender y llenarlo de SPAM y el Admin no va a poder eliminar dichos posts... y tampoco recibira Error no Warnings recibira nada... Y asumo que lo mismo podria ocurrir a la hora de Banear a un usuario por su nick.

Por eso posteo eso aca, porque aunque es dificil lograr acceder como admin a un motor MySQL para hacer estos cambios, siempre buscan la via de llegar, y no es nada gracioso para ningun DBA ver que no puede borrar ni actualizar datos del motor y No saber porque.

Un saludo.

Nakp

Muy buena info... no se por que no hiciste lo que haré :xD
Ojo por ojo, y el mundo acabará ciego.

^Tifa^

No tengo idea de lo que haras....  :huh: pero espero que no sea negativo. Lo coloque aca porque aparentemente el equipo de desarrollo de SUN no esta en arreglar cosas internas de MySQL a no ser que sean extremadamente muy graves. Y puestos que ellos ignoraron el reporte y me dieron una respuesta un poco tonta y muy diferente a lo que yo les pregunte.... pues pense que era beneficioso colocar la info aca, mas para tener eso pendiente no para hacerle una broma a nadie.

El asunto se puede resolver haciendo un backup de toda la tabla, y al archivito de backup editarlo y colocarle VARCHAR y volver a cargar todos los datos ... pero imaginate un sitio de millones de datos ya alojados, y tener que empenarse a hacer el backup primero, luego editar el archivo y finalmente cargar todosss esos datos  :xD  algunas horas fuera de online sin duda.

En fin, para hacer lo anterior deberias tener acceso full a la tabla a la cual le haras el ALTER aunque con tanto hackeo y exploits que hay por ahi, no dudo que obtengan esto.

Nakp

ponerle chincheta :P eso hice xD

ni hace gracia hacer backup de miles o millones de datos, ni que respondan como deban... pusiste este ejemplo en el bugtracker? yo volvería a abrirlo con un link para que entiendan xD
Ojo por ojo, y el mundo acabará ciego.

^Tifa^

Lo puse en el Bugtracker... pero por mas que le cree el escenario con ejemplos y los pasos de prueba, y les especifique que el comando ALTER no cambiaba internamente el tipo de dato aunque visualmente 'Si' ellos... cerraron el tema diciendo que no era un BUG y diciendome que BINARY solo lee caracteres como binario (Algo que ya yo sabia) pero obviaron a toda costa el porque ALTER no aplica cuando cambias de tipo de dato.

No es la primera vez, que reporto algo en el bugtracking de MySQL y los developers hacen lo imposible por cerrar el reporte y hacer caso omiso. Hace un tiempo reporte uno donde eliminabas un tablespace y esto causaba que se eliminaran todos los tablespaces previos a la creacion de este ultimo ... en resumen perdias tablas de otro tablespace  :xD y obviamente al perderlas no habia forma de recuperar nada. Ese reporte tambien me lo cerraron alegando que no era un BUG y unas semanas despues otro developer lo abrio nuevamente, y estaba preguntandole a quien le habian asignado el reporte que porque lo cerro si efectivamente el podia reproducir este bug en su MySQL.. y bueno mas developers se unieron y crearon un parche porque dedujeron que efectivamente era un BUG. Pero es normal que esos developers cierren casos para trabajar menos, ya me he enfrentado a estos casos y esta vez no voy a volver a abrir algo que ya he reportado.

[u]nsigned

Impresionante. Muy buena info (para ser sincero no entiendo con exactitud el bug xD), pero posteo porque quizás los de MySQL no te dan bola(con perdon de la expresion  :¬¬) por esto:

http://vivalinux.com.ar/soft/fin-del-soporte-de-mysql-5.0
Citar
A partir del próximo 1 de Enero del 2010 MySQL 5.0 caerá efectivamente dentro del programa de "Soporte Extendido" de Sun Microsystems, y por los siguientes dos años, hasta el 31 de Diciembre del 2011, sólo errores serios y vulnerabilidades de seguridad serán corregidos pero sólo para clientes que hayan pagado por alguno de sus contratos de mantenimiento "Silver" (U$S 1.999 por año), "Gold" (U$S 2.999 por año) o "Platinum" (U$S 4.999 por año).

Saludos

No hay atajo ante la duda, el misterio se hace aquí...
Se hace carne en cada uno, el misterio es existir!

^Tifa^

Hola.

Para los que todavia no comprenden el bug (que es mas de funcionalidad del motor que otra cosa) el bug es que si tienes una tabla con campos VARCHAR y haces un alter sobre esa tabla (para cambiar el tipo de dato de los campos de VARCHAR a BINARY) el te accepta el cambio, pero despues no puedes eliminar ni actualizar ningun registro (data) dentro de la tabla. No sirve que vuelvas a alterar la tabla para cambiarla como estaba (acceptar tipos de datos VARCHAR) ya que no funciona, sigue sin hacer ningun cambio al tratar de eliminar o actualizar datos. El problema creo es como MySQL maneja el tipo de datos BINARY.

un saludo.

Skeletron

Increible...
Es un error super super importante...

Como puede ser que no esté solucionado?

SANSARA

Orale Interesante , a decir vdd tampoco  comprendi mucho  del bug .. pero con tu explicacion ta quedas con la duda de .. el por que no le hicieron caso a tu  comentario ...


S   A    M   S   A   R   A

[u]nsigned

Perdon por el offtopic, pero en uno de mis viajes misticos tuve una vision..

No sera acaso que Oracle (nuevo duenio (teclado americano  :xD) de SUN y por ende de MySQL) no quiera de alguna forma ir poniendole palos en la rueda a toda competencia de su producto extrella?

Donde estariamos si no fuera por MySQL y PostgreSQL?  :silbar:

Saludos

PD: Tuve la misma vision para OpenSolaris...

No hay atajo ante la duda, el misterio se hace aquí...
Se hace carne en cada uno, el misterio es existir!