Exportar tabla utf8 con contenido latin1

La locura de los mysql es tener la tabla con una codificación la columna con otra y la conexión al servidor con otra distinta.
Puede llegar a ser un auténtico caos, y cuando lo tienes más o menos claro , viene otro punto complicado, como modficio mis datos para gestionarlos correctamente.

En un caso que me ha ocurrido hoy he solucionado el problema volcado la base de datos así :

[shell]
mysqldump -p -u root –add-drop-table –quote-names –compatible=ansi -N greengedients > /tmp/greengedients.sql ;
[/shell]

Este volcado omite información de ‘characters’ con lo cual puedo importarlo de forma mas o menos aseptica ya que puedo controlar el set de caracteres desde la consola de myql con el comando
[sql]
SET NAMES utf8 ;
[/sql]

en mi caso no ha sido necesario nada más que volvar y volver a importar para que el contenido se haya convertido entéramente en UTF8 y no en un híbrido .

mal uso de parámetros en un array con consultas preparadas con cakephp y mysql

Vaya chorro de título….. qué es esto ?

Pues explicado muy muy rápido si quiero preparar una consulta bonita para lanzar a la base de datos ( mysql ) y que tenga parámetros en vez de hacer chapuzas y guarrerías varias que se ven en muchos sitios , uniendo strings y demás…. se pueden usar parámetros.

Es muy sencillo, queda de esta forma :

[sql]

SELECT Customer.name FROM customers Customer WHERE Customer.id = :customer_id

[/sql]

Si veis ‘:customer_id’ no pertenece al standard de SQL , es un parámetro . De forma que le puedo pasar a la consulta una variable como cuando usamo printf y Mysql construirá la query completa, además de hacer cosas con los índices y demás … que no vamos a tratar ahora.

Pues bien. tengo aquí un caso real de una cosa que me ha pasado hoy, quería pasar por parámetros un array de parámetros de forma que quería buscar ‘customer.id IN ( :listaIDs ) ‘. Os adelanto ya que no se puede pasar un parámetro que sea un string de integers separados por coma.

[php]

public function getCustomersById( $objectIds = array() ) {
$sql = ‘
SELECT
Customer.*
FROM
customers Customer
WHERE
Customer.id IN ( :objectIds ) ‘;

$db = $this->getDataSource();

$objectIds= join( ‘,’, $object_id );
$params = array (
‘objectIds’ => $objectIds
);

return  $db->fetchAll($sql, $params  )

}

[/php]

Pues esta consulta sólo retorna los resultados que coincidan con el último valor del array. Si veis hago un join() para unir los valores y pasarlos como parámetro. Pues Mysql se lo come y sólo utiliza el último, tampoco da error. Qué alegrías que nos da la programación 😀

 

Xeround deja de ofrecer servicio gratuito

Xeround ‘The cloud database’ deja de ofrecer servicio gratuito de base de datos el 15 de Mayo de 2013. Según la nota en su página web :

We are deeply sorry to inform you that Xeround’s public cloud offering will be discontinued as of May 15th, 2013.

Xeround’s leadership forum has recently decided to re-focus the company’s effort. This means we will no longer be able to support our service over public clouds.

It is with genuine sadness that we inform you that Xeround’s service will be terminated in 2 weeks, across all of our currently active data centers.

Esto supone el fin de servicio a miles de bases de datos en las próximas dos semanas.
Algunos proveedores como Orchestra sugieren pasarse a «Amazon’s Relational Database Service» :

We’re sorry to inform you that Xeround is discontinuing it’s public cloud database offering. As a result, any free databases that you may have created via the Xeround add-on with Orchestra PHP Cloud will be terminated on May 8th, at 00:00 EDT.

So that your application doesn’t experience any downtime, it is crucial that you migrate your database before that time. Our suggestion is to use Amazon’s Relational Database Service. And one of our support engineers will be happy to assist you with that migration.

Apologies for the short notice. Xeround only announced this news yesterday. But we will do everything we can to ensure a seamless transition for you.

mysql Optimizando tablas grandes de forma alternativa

Si teneis alguna base de datos con unos cuantos millones de registros y se os ocurre lanzar un ‘OPTIMIZE TABLE…’ os podrán dar las tantas de la noche que eso tarda rato largo… Hay otra forma un poco menos convencional que puede ayudar a optimizar los datos, se trata de volcar el contenido a otra tabla nueva y cargarnos la original:

En este ejemplo, nos cansamos de lo que tarda la optimizacion:

mysql> optimize table tabla_enorme ;

^CQuery aborted by Ctrl+C
+------------------------------+----------+----------+---------------------------------+
| Table                        | Op       | Msg_type | Msg_text                        |
+------------------------------+----------+----------+---------------------------------+
| mibasededatos.tabla_enorme   | optimize | error    | Query execution was interrupted | 
| mibasededatos.tabla_enorme   | optimize | status   | Operation failed                | 
+------------------------------+----------+----------+---------------------------------+
2 rows in set, 1 warning (32 min 9.54 sec)

Con 32 minutos ya basta 😀 y aún le quedaban horas.

Si hacemos el volcado a una nueva tabla :

mysql> create table tabla_enorme2 ( select * from tabla_enorme );
Query OK, 16638600 rows affected (2 min 9.44 sec)
Records: 16638600  Duplicates: 0  Warnings: 0

mysql> create index puntos_id_order on tabla_enorme2 (id_order) ;
Query OK, 16638600 rows affected (2 min 24.39 sec)
Records: 16638600  Duplicates: 0  Warnings: 0

mysql> 
mysql> rename table tabla_enorme to tabla_enorme_old;
Query OK, 0 rows affected (0.14 sec)

mysql> rename table tabla_enorme2 to tabla_enorme ;
Query OK, 0 rows affected (0.00 sec)

En 5 minutos lo tenemos hecho y nos sobra para insertar unos indices y tal 😀

ERROR 1153 (08S01) at line xxxx: Got a packet bigger than ‘max_allowed_packet’ bytes

Al ejecutar un script sql puede aparecer este error:

ERROR 1153 (08S01) at line 40699: Got a packet bigger than ‘max_allowed_packet’ bytes

Lanzamos esta consulta para ver el limite[/shell]

mysql -uadmin -p`cat /etc/psa/.psa.shadow ` -e "show variables like '%max_allowed%'"[/shell]

+--------------------+---------+
| Variable_name | Value |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+[/shell]

Para solucionarlo ampliamos el limite sólo para la consulta:[/shell]

[shell]mysql -u admin -p`cat /etc/psa/.psa.shadow ` --max_allowed_packet=256M database < export.sql[/shell][/shell]