Mensajes

Si me he unido al club    aunque desconozco aun hasta que nivel de aprendizaje.

Sigo observando la considerable rapidez de respuesta de Perl como CGI vs Python como CGI.

Pero... nunca esta demas agregar un lenguaje script mas al repositorio de la cabeza. 

Me he unido al club 

Otra forma rapida tambien.

Código (python) [Seleccionar] Expandir



import os

os.system("firefox www.google.com")



Por ejemplo 

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  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.

No tengo idea de lo que haras....  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    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.

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    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] Expandir



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    ahora que ocurre si se quiere actualizar o eliminar algun dato, observen:

Código (sql) [Seleccionar] Expandir



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] Expandir



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] Expandir



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] Expandir



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] Expandir



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] Expandir



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.

Es bueno optimizar el codigo o al menos intentarlo. Optimizar el codigo solo funcionara para conocer el lado de consumo del codigo como tal.. esto es totalmente independiente de las consultas a la base de datos (Sobretodo por lo que les expuse anteriormente, donde los datos se guardan en un buffer de la libreria que trabaja con el motor de DB). Es un proceso un poco extenso si te dedicas al tema, pero como es algo que me encanta hacer    suelo depurar primero base de datos con profiling, luego al codigo fuente con Benchmark 

fede_cp si quieres obtener el rendimiento de un programa entero como dices, debes crear un archivo que funcione de 'main' o principal y dentro de este inicializar el objeto Benchmark, y ir llamando las funciones de modulos por modulos el caso es que cuando termines de llamar funciones de modulos, finalizar el objeto Benchmark he imprimir el resultado en pantalla o enviarlo a un archivo 

Que bien 

Yo suelo utilizar Benchmarking en Perl cuando trabajo con el modulo DBI para base de datos. Asi me entero cuanto tarda mi codigo Perl en obtener unos datos o realizar una consulta a los datos en el Buffer de la libreria DBI.

Benchmark es un modulo no se en PHP pero en Perl viene por defecto con el interprete, y es bastante efectivo para enterarse del consumo de CPU y memoria del codigo como tal.

Buen aporte para PHP digo    ya imagino que muy pocos utilizan Benchmark para optimizar sus codigos.

No se en que punto todavia no te aclaras....

En las tablas que yo he creado de ejemplo, hay una relacion el campo ID de ambas tablas, vamos que no es tan dificil de ver 

Dejame intentar desglosar porque creo que tienes una pekena confusion en cuanto a las relaciones de entidades y si un motor es o no transaccional. Basandome en la manera como tu percibes cuando unos datos estan o no relacionados en varias tablas (que para ti solo aplican si el motor es transaccional) el ejemplo posteado por mi, y por casi todos los demas (sino todos) tambien estan erroneos. Porque ellos se basaron en el modelo entidad-relacion de datos, ellos no se han basado de si el motor es o no transaccional, son dos cosas distintas.

Cuando te dicen que un motor de almacenamiento es transaccional te estan diciendo que tiene unas funcionalidades (No las voy a describir todas aqui que conste, solo las basicas para ver si te aclaras un poco) dentro de estas funcionalidades existe el control de forma automatica entre 2  o mas tablas, donde hay una tabla 'padre' y una tabla 'hijo' este control lo que hace es precisamente, que si se actualiza o elimina un dato en la tabla padre aplica automaticamente a la tabla hijo (Siempre y cuando pusieras dicha condicion a la tabla hijo con ON UPDATE y ON DELETE) ahora, si te fijas bien yo te he recreado de forma basica esa mismita funcionalidad en 2 tablas bajo motor NO transaccional, como lo hice?? con los TRIGGERS que te postee. Estoy en este caso haciendo lo mismo que si ambas tablas fuesen transaccionales (En este unico punto ojo que no quiero personas que asuman que estoy comparando transaccional vs no transaccional) lo unico que yo misma cree la condiciones con 2 TRIGGERS, mientras un motor transaccional como InnoDB lo hace ya por defecto de forma automatica porque esta programado a funcionar asi.

Cuando te dicen un motor No transacional, te estan diciendo que las funcionalidades de las cuales carece este motor es precisamente el control automatico de lo que ocurre entre la tabla padre o la tabla hijo (Hay mas diferencias que conste, pero no aplica extenderlas para lo que requieres aclararte). Por esta razon si yo tomo este modelo y lo coloco bajo un motor no transaccional, como yo controlo las transaciones de ahi me vere obligada a implementar de alguna manera las funcionalidades basicas que controlen los cambios de una tabla padre a una tabla hijo, por eso viste que cree 2 TRIGGERS sencillos que me manejaran los UPDATE y DELETE de la tabla padre hacia la tabla hijo.

Las relaciones entre tablas se basan por las entidades que componen las tablas llamase campos, no es obligatorio que este en un motor transacional o no, las relaciones de datos es una cosa, la funcionalidad de control sobre esos datos es otra cosa y te lo he expuesto mas arriba.

[S[numero]local]

Que raro que el kernel no cree el nodo el mismo  puedo sugerirte intentar hacer lo siguiente, aunque no garantizo 100% que funcione.

Entra a tu Ubuntu por el kernel 14. En el entorno grafico cuando te loguees, abre un editor grafico y agregale las siguientes lineas:

#!/bin/sh

mknod /dev/mem c 1 1
chgrp kmem /dev/mem
chmod 640 /dev/mem

Guarda ese archivo con el nombre 'local.sh' (Puede ser otro pero puse local)

Ahora abre una terminal y haz:

bash$ cp local.sh  /etc/init.d
bash$ cd /etc/init.d
bash$ sudo chmod +x local.sh
bash$ ln -s local.sh  /etc/rc3.d/S[numero]local
bash$ ln -s local.sh /etc/rc5.d/S[numero]local

Donde S[numero]local Aca debes tener cuidado, ingresa a ambas carpetas /etc/rc3.d  y /etc/rc5.d y verifica (con el comando ls) de todos esos servicios que vez alli cual tiene el ultimo numero asignado, cuando verifiques suponiendo que el ultimo numero es S98comando  tu vas a colocarle entonces: S99local al enlace simbolico que estas creando.

Cuando tengas eso reinicia el sistema y elige el kernel 16 si vuelve a darte error, entonces reinicia nuevamente y  cuando llegues al GRUB elige el kernel 16 y pincha la tecla 'e' para editarlo, bueno luego vete a fin de linea y modifica lo que esta en negrita:

kernel /boot/vmlinuz-2.6.27-7-generic root=UUID=aqui el Serial de tu HD ro quiet splash rootdelay=130

Luego pulsas 'Enter' y la tecla b para continuar

Prueba haber si va.

Imagina que tengo estas 2 Tablas con los siguientes datos:

Código (sql) [Seleccionar] Expandir


mysql> select * from relacion;
+------+--------+--------+   
| id   | codigo | nombre |   
+------+--------+--------+   
|    1 |      2 | Luis   |   
|    1 |      3 | Marta  |   
|    2 |      4 | Jose   |   
|    2 |      1 | Marian |   
+------+--------+--------+   
4 rows in set (0.00 sec)     

mysql> select * from usuarios;
+----+--------+               
| id | nombre |               
+----+--------+
|  1 | Marian |
|  2 | Luis   |
|  3 | Marta  |
|  4 | Jose   |
+----+--------+
4 rows in set (0.00 sec)


Y yo quiero controlar que cuando actualize o elimine un dato de la tabla usuarios se aplique en la tabla relacion
justo como lo haria las tablas si usase un motor de almacenamiento transaccional como InnoDB, la diferencia es que
estas 2 tablas estan bajo el motor no transaccional Myisam... entonces como tu controlas esto? con la creacion de
triggers como te venia comentando:

Código (sql) [Seleccionar] Expandir


mysql> delimiter /
mysql> create trigger trigo
    -> after update on usuarios
    -> for each row           
    -> begin                   
    -> update relacion set id = NEW.id where id = OLD.id;
    -> end;                                             
    -> /                                                 
Query OK, 0 rows affected (0.06 sec) 
mysql> delimiter ;

mysql> update usuarios set id = 6 where id = 1;
Query OK, 1 row affected (0.04 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from relacion;
+------+--------+--------+
| id   | codigo | nombre |
+------+--------+--------+
|    6 |      2 | Luis   |
|    6 |      3 | Marta  |
|    2 |      4 | Jose   |
|    2 |      1 | Marian |
+------+--------+--------+
4 rows in set (0.00 sec)

mysql> select * from usuarios;
+----+--------+
| id | nombre |
+----+--------+
|  6 | Marian |
|  2 | Luis   |
|  3 | Marta  |
|  4 | Jose   |
+----+--------+
4 rows in set (0.00 sec)


Viste como actualice data en la tabla usuarios y automaticamente se aplico en la tabla relacion
como si estuviesen bajo un motor de almacenamiento transaccional, cuando no lo esta?
Ahora si quisieras aplicar el 'ON DELETE CASCADE' por ejemplo que si eliminas una fila en
la tabla usuarios tambien se elimine de forma automatica en la tabla relacion.

Código (sql) [Seleccionar] Expandir


mysql> create trigger trigo1
    -> after delete on usuarios
    -> for each row
    -> begin
    -> delete from relacion where id = OLD.id;
    -> end;
    -> /
Query OK, 0 rows affected (0.40 sec)

mysql> delimiter ;

mysql> delete from usuarios where id = 2;
Query OK, 1 row affected (0.00 sec)

mysql> select * from usuarios;
+----+--------+
| id | nombre |
+----+--------+
|  6 | Marian |
|  3 | Marta  |
|  4 | Jose   |
+----+--------+
3 rows in set (0.00 sec)

mysql> select * from relacion;
+------+--------+--------+
| id   | codigo | nombre |
+------+--------+--------+
|    6 |      2 | Luis   |
|    6 |      3 | Marta  |
+------+--------+--------+
2 rows in set (0.00 sec)



Lo anterior expuesto, no fuese posible de realizar sino existiera una relacion de identidad iguales de campos entre el campo ID de ambas tablas. Los datos no tienen que estas de manera obligatoria sobre tablas con motor InnoDB para poder funcionar (A nivel de relacion) como un motor transaccional lo haria. Pero especifico a nivel de relacion de campos no al nivel de todas las funcionalidades que posee un motor transaccional real como son los indices clustered en vez de b-tree, el lockeo de filas en vez de toda la tabla, entre otras cositas internas que poseen los motores transaccionales que no sera aplicable en motores no transaccionales, pero... en el caso que pides no es requerido exponer esto ni abundar tanto, lo que pides se puede controlar con TRIGGERS en motores no transaccionales como puedes ver... y obviamente asi como controlas que campos se actualizan y eliminan de la tabla relacion cuando hacemos algo en la tabla usuarios, puedes crear TRIGGERS que impidan que se actualice o elimine campos sobre relacion sino se ha aplicado nada en la tabla usuarios.