mysql

Convert dates from UNIXTIME in mysql

Reading a date in mysql can be frustrating, unless your brain is able to convert Dates from UNIXTIME formats. Let's see for example this scenario in Drupal:

SELECT * FROM `node` ORDER BY `node`.`created` DESC LIMIT 0 , 30

If you need to fetch, for example, when it was the last time that a node was created, this format doesn't help too much.

The solution is quite simple, FROM_UNIXTIME( field_with_date )

For example:

SELECT * , FROM_UNIXTIME( created ) FROM `node` ORDER BY `node`.`created` DESC LIMIT 0 , 30

categorias: 

ERROR 2013 (HY000): Lost connection to MySQL server

Have you ever had a big (and when i say big I mean BIG) database which you need to import in a sql file?

If so, you'll probably have found this issue (or even you are having the problem just now and you are reading this looking for a solution):

ERROR 2013 (HY000): Lost connection to MySQL server

This uses to happen when trying to import the dump with the mysql -u command:

mysql -u root -p database < databasetoimport.sql

You can try to play with the my.ini settings, but a best secure solution is just to do the import from the mysql own console. How? easy.

1. go to the place where your sql is. Then log in mysql:

mysql -uroot -p

2. create the database if needed:

create database mynewdb

3. Change to it:

use mynewdb;

4. and finally, import it:

source databasetoimport.sql

Wait and hopefully the problem will not appear again.

The reason is simple. Mysql is designed to have this behabiour of closing the connection dealing with external scripts, like php or the own mysql command. If you are executing the import from inside the console, the problem will not appear.

Problems with mysql 5.5 upgrading ubuntu 12.04

After upgrading ubuntu to 12.04 i have run into problems with mysql.

First of all, if you are going to make an upgrade of "anything", the main tip is to make a backup of the databases and files which you consider important. If you didn't, maybe you still can save something, copy your /var/lib/mysql directory. If you finally have to reinstall your mysql, loosing the databases, maybe you will be lucky and copying again /var/lib/mysql directory could give your data back.

ok, the problem with mysql 5.5 and ubuntu 12.04.

The following packages have unmet dependencies:

 mysql-server : Depends: mysql-server-5.5 but it is not installed

E: Unmet dependencies. Try using -f.

Trying apt-get -f install did not solve anything. Tryied then apt-get install mysql-server-5.5

No luck, but then i saw this:

trying to overwrite '/usr/lib/mysql/plugin/ha_example.so', which is also in package libmysqlclient-dev

And the solution came to my mind: remove the conflictive package:

sudo dpkg -r libmysqlclient-dev

and now, 

apt-get -f install 

finally worked and did the magic. I did backups of my important databases before going to this "party", but anyway, after installing again mysql (apt-get -f intall did) everything was working fine, mysql included.

Hope it helps :-)

eliminar una fila en una base de datos

 

DELETE FROM `bbdd`.`table` WHERE `crucero`.`agencia` = "AGENCIA";

 

categorias: 

migrar contenido de drupal a drupal con mysql y phpmyadmin

Atención: lo siguiente es una administración de Drupal de guerrilla. No os recomiendo llevarla a cabo a menos que realmente sepáis que lo necesitáis y sabéis lo que estáis haciendo. Igualmente, un backup antes de poneros en harina es altamente aconsejable. Si pierdes datos o la base de datos entera no me hago responsable de las consecuencias, lo que vas a leer a continuación es sólo apto para no cardíacos, y por tanto si sigues alguna de mis indicaciones lo haces por tu cuenta y riesgo :-).

Caso expuesto: migrar contenido de un drupal a otro, siendo el segundo un Drupal en marcha (más de 6.000 nodos y unos 1.000 usuarios) y el primero con unos 600 nodos y otros 500 usuarios aprox.

Primer paso, backup:

  • mysqldump --opt -uUSER -pPASS BBDDaMigrar  > BBDDaMigrar-BACKUP.sql
  • mysqldump --opt -uUSER -pPASS BBDDaMigrar  > BBDDaRecibirMigracion-BACKUP.sql

 

Segundo paso, migrar los nodos (del Drupal a migrar, se entiende):

  • CREATE TABLE node2 LIKE  node; #creamos una tabla sobre la que jugar
  • INSERT node2 SELECT * FROM node;

 

Repetimos con node_revisions:

  • CREATE TABLE node_revisions2 LIKE node_revisions;
  • INSERT node_revisions2 SELECT * FROM node_revisions;
  •  

Y con los tipos de contenido que tengamos a medida:


    • CREATE TABLE content_type_empresa2 LIKE content_type_empresa;
    • INSERT content_type_empresa2 SELECT * FROM content_type_empresa;

 

La tabla node_type no contiene nid ni datos de este tipo que tengamos que adaptar, solo una descripción por nombre del tipo de contenidos. Por lo tanto, no hace falta migrarla, simplemente nos aseguramos de que existe el tipo de contenido en la base de datos o el Drupal que va a recibir los nodos (page, blog, ... los estándar y cualquier tipo nuevo que hayamos creado nosotros o el admin del sitio).

Ahora volcamos estas tablas en el Drupal que vaya a recibir los datos:

primero, backup de las tablas:

  • mysqldump -uUSUARIOMYSQL -pPASSMYSQL nombreBBDDOrigen node_revisions2 > node_revisions2.sql
  • mysqldump -uUSUARIOMYSQL -pPASSMYSQL nombreBBDDOrigen node2 > node2.sql
  • mysqldump -uUSUARIOMYSQL -pPASSMYSQL nombreBBDDOrigen node_revisions2 > node_revisions2.sql

 

segundo, volcamos el backup en el Drupal receptor.

  • mysql -uUSUARIOMYSQL -pPASSMYSQL nombreBBDDDestino < node_revisions2.sql
  • mysql -uUSUARIOMYSQL -pPASSMYSQL nombreBBDDDestino < node2.sql

Ahora tenemos los nodos en la base de datos final. Sin embargo los datos nuevos tienen ids que coincidirán con los que ya existan en Drupal (en el receptor, se entiende). Solución? Contar los nodos que ya existen y sumar ese número al nid de los nodos que hemos traido a la base de datos. Por ejemplo, en mi caso teníamos unos 6000 y pico nodos. El nid nuevo será 7.000 + nid.

No nos preocupamos por nada más ya que Drupal se encargará de asignar a los nuevos nodos los ids correctos, teniendo en cuenta los nuevos nodos que han aparecido en la base de datos.

Vamos allá:

  • UPDATE  `node2` SET  `nid` = `nid` + '7000';
  • UPDATE  `node_revisions2` SET  `vid` = `vid` + '7000';
    UPDATE  `node2` SET  `uid` = `uid` + '500'  ;

    • UPDATE  `node_revisions2` SET  `nid` = `nid` + '7000'  ;

      

idem con content_..._empresa, o los tipos de contenido que tengamos "a medida":

  • UPDATE  `content_type_empresa` SET  `nid` = `nid` + '7000';
  • UPDATE  `content_type_empresa` SET  `vid` = `vid` + '7000';
  • UPDATE  `content_type_empresa` SET  `uid` = `uid` + '500'  ;

 

cuidado con esto último. El nodo pertenece a un usuario de la BBDD anterior, con lo que también hay que, tanto en node, noderevisions y content, modificar el nuevo usuario.

Bien, en este punto ya estamos listos para volcar estas tablas en su sitio definitivo...o más bien para concatenar las tablas que ya tenemos con estas nuevas.

Primero, una vez más, backup de lo que tengamos:

 

  • mysqldump -uUSUARIOMYSQL -pPASSMYSQL nombreBBDDOrigen node_revisions > node_revisions.sql
  • mysqldump -uUSUARIOMYSQL -pPASSMYSQL nombreBBDDOrigen node > node.sql

 

Segundo, pasamos concatenamos los nuevos nodos, que es justamente el proceso inverso con el que empezamos todo este "lio":

 

    • INSERT node SELECT * FROM node2;
    • INSERT node_revisions SELECT * FROM node_revisions2;
    • INSERT content_type_X SELECT * FROM content_type_X2;

 

 

Y, si no ha habido ninguna incidencia, tenemos una bonita base de datos con el número de nodos total justamente igual a la suma de los nodos de ambas webs en Drupal, ni más ni menos, y con id's que son:

para la base de datos "receptora", los nid son los mismo,

para la base de datos que "aluniza" en esta base de datos, el nid que tuviera antes más la constante que hayamos elegido como precaución (en nuestro caso 7.000).

En otro post tocaremos el tema de las taxonomías, y cómo podemos migrarlas sin que se produzcan colisiones a la vez que los posts no pierdan sus respectivas clasificaciones.

Importar / Exportar de Drupal a Drupal usando SQL

En drupal hay un montón de módulos para realizar migraciones, como migrate, user_import, node_import... o incluso el fantástico Feeds, que te permite partir de casi cualquier fuente, como xml, cvs,... y fuentes tan difersas urls, ficheros, ...

Ahora bien, a veces es más sencillo, sabiendo un poco de sql y organizandose uno mismo la migración, hacerlo directamente a mano. Es el caso de una migración, una importación más bien de usuarios de un Drupal a otro. No me preguntéis como me he metido en tal lio, pero a veces pasa... "shit happens" decía un amigo.

Y, como decía otro amigo... que demonios, los hombres de verdad programan en C a "pelo" y con vi sin plugins ni mari*** de esas :-).

Vamos allá:

i) Pasar tablas:

  • CREATE TABLE users2 LIKE users;
  • INSERT users2 SELECT * FROM users;

 

Actualizamos el uid para que no "choque" con el de la base de datos en la que vamos a volcarlo:

  • UPDATE  `users2` SET  `uid` = `uid` + '500'  ;

 

Esto suma 500 a todos los uid que existan (no hay where ni limit, con lo que la consulta se hace para todas las tablas y no se pone limitación.

En mi caso el número de usuarios era de 400 y pico, casi 500. En vuestra tabla tendréis que comprobar el último uid y cambiar la cifra. Da igual cuál usemos puesto que Drupal usa autoincrement, con lo que mientras no solapemos uids, drupal "cazará" la última que exista (1000 y pico en mi caso) y continuará trabajando desde ahí.

Ahora hacemos backup SOLO de la tabla: 

  • mysqldump -uUSUARIOMYSQL -pPASSMYSQL nombreBBDDOrigen users2 > users2.sql

 

y nos la llevamos a la otra base de datos

 

  • mysql -uUSUARIOMYSQL -pPASSMYSQL nombreBBDDDestino < users2.sql

 

Excelente. Ya tenemos la base de datos con las dos tablas juntas (origen y destino) y con los uids incrementados de forma que no se solapen entre ellos. No habría problema si no lo hemos hecho bien porque al hacer el import mysql se "quejaría" de que ya existe un dato con ese uid (que debe ser único).

Ahora hacemos justo lo contrario de lo que habíamos hecho al inicio:

 

  • INSERT users SELECT * FROM users2;

 

con lo que la nueva tabla pasará a la tabla users... y drupal ni se habrá dado cuenta :-).

 

Huelga decir que este procedimiento puede aplicarse a cualquier tabla, por ejemplo a la tabla node, donde residen los nodos, la tabla content_TIPOCONTENIDO, donde residen los contenidos de CCK, ...

Notas:

Hay otra forma de crear la tabla users2 más rápida, que es la siguiente:

create table users2 select * from users;

De esta forma genera la tabla users2 e importa de una todos los datos de users.

categorias: 

Actualizar comentarios en drupal desde mysql

Un pequeño truco. En un determinado momento me vi con el problema de varios cientos de nodos en Drupal publicados con los comentarios cerrados.

Solución? Muy sencilla:

 

UPDATE node SET comment = '2' WHERE type = 'tipo_contenido';

(cambiar tipo_contenido por el contenido correspondiente, que además suele coincidir tipo_contenido con el nombre del contenido que hayamos creado en Drupal.

 

categorias: 

backup y restore (volcar) una base de datos mysql

Cambiar de servidor una base de datos? Ningún problema

el primer paso, sencillo, hacer el backup:

mysqldump -a -u admin -p DATABASE > FILENAME.mysql

--default-character-set=latin1 table >

(esta última linea es opcional)

1.Drop the database

mysqladmin -u admin -p drop DATABASE

(idem, si queremos eliminarla estupendo, pero por seguridad yo la dejaría en su sitio)

2.Recreate the database

mysqladmin -u admin -p create DATABASE

-esto lo hacemos ya en el nuevo servidor

3.Import the backup data

mysql -u USER -p PASSWORD DATABASE < FILENAME.mysql

mysql -u admin -p < .mysql

 

Otras notas:

Hacer backup de varias bases de datos:

mysqldump -u username -ppassword –databases db_name1 [db_name2 ...] > dump.sql

 

TODAS LAS BASES DE DATOS:

mysqldump -u username -ppassword –all-databases > dump.sql

 

categorias: 

Obtener el id más alto en mysql

Ahora mismo andaba buscando como saber cuál es el id más alto introducido en una base de datos MYSQL. Algunos lenguajes te permiten, incluido SQL, obtener la última consulta realizada con "autoincremente". Sin embargo buscaba algo a más "bajo nivel".

Concretamente lo estaba buscando para ruby, pero en verdad la solución en SQL es más eficaz puesto que "abstraes" la complejidad del lenguaje delegando todo el proceso al propio SQL.

Solución? Muy fácil, desde sql:

SELECT MAX(nid)  FROM table

Usando php:

 $sql = "SELECT MAX(ID) FROM tbl";
 $result = mysql_query($sql);
 $row = mysql_fetch_row($result); 
$max_id = $row[0]; 

Usando Ruby:

lastid = dbh.query("SELECT MAX(nid)  FROM node_revisions")

 

Enlaces relacionados:

http://www.codingforums.com/showthread.php?t=1552

categorias: