Configurar usuario default PostgreSQL para uso local

Mucho tiempo sin andar por acá... a ver que tal sale.

Ahora me recordé que debía configurar mi PostgreSQL en Ubuntu a que funcione de manera local lo más fácil posible para poder hacer los trabajos de desarrollo que tengo acá.

De esta manera fue que me puse a trabajar en recordar que había que hacer y acá pongo el procedimiento para habilitar de manera fácil al usuario default para acceder a las bases de datos de PostgreSQL desde localhost y con aplicaciones como pgAdmin por ejemplo.

Primero

Cambiar contraseña del usuario 'postgres' del sistema. Por las dudas dejarle una contraseña que podamos recordar par a el usuario en nuestro sistema operativo a través del comando en shell:

#passwd postgres

Segundo

Permitir conexiones escucha (listening) para conexiones desde 'localhost'. Para lo cual debemos modificar el archivo postgres.conf  (En Ubuntu está en /etc/postgres/9.1/main/) en la línea :

# - Connection Settings -

listen_addresses = 'localhost'   #<-si comentada="" descomentar="" est="" esta="" font="" hay="" linea="" que="">

Tercero

Ahora debemos cambiar el usuario también de la base de datos de usuarios de postgres la cual usa este manejador para gestionar el acceso de usuarios a su base de datos. Lo hacemos con los siguientes:

# su postgres
postrgres@local:$ psql
postgres=#  ALTER USER user_name WITH PASSWORD 'new_password';
postgres=# \q       

¡¡¡Listo!!!

Ahora ya deberíamos poder acceder a nuestra base de datos desde aplicaciones como pgAdmin o conexiones desde nuestro mismo equipo para hacer todos los desarrollos que se requieran.

Hasta la vista javer@s!!!

Acelerar importación de Base de Datos MySQL desde consola

HOla!
Esta ocasión platico lo que me pasó. Tratando de cargar una base de datos bastante grande (una tabla cuyo sql era de aprox 6GB), me encontré con la dificultad de que al importarlo a través de la linea de comandos de MySQL tardaba un demonial, más de lo que podría suponerse, tardando 20 segundos o más por cada 1000 registros (hablábamos de unos 5 millones de registros).
Me di cuenta que el dump lo habían generado desde una útil herramienta llamada SQLyog y que mi compañero desde su máquina haciendo el import con la misma herramienta tardaba muuuucho menos que yo.
Entonces vi que el archivo sql del dump no contenía ninguna clase de comentario ni directiva extra más que la carga de los datos, es decir, el create de la tabla y los inserts, ¡Ah claro! y que había sido hecho por SQLyog.

Encontré una página con algunas estrategias para acelerar los procesos de dump y de importación:

Aquí

Entre ellos uno me llamó la atención y parece la solución a mi problema. Al restaurar desde consola en linux sería bueno activar las directivas para cancelar varios chequeos que hace MySQL y acelerar el proceso.

(
    echo "SET AUTOCOMMIT=0;"
    echo "SET UNIQUE_CHECKS=0;"
    echo "SET FOREIGN_KEY_CHECKS=0;"
    cat dump.sql
    echo "SET FOREIGN_KEY_CHECKS=1;"
    echo "SET UNIQUE_CHECKS=1;"
    echo "SET AUTOCOMMIT=1;"
    echo "COMMIT;"
) | mysql -u... -p... target_database

o podemos crear un archivo para ejecutar desde el shell:

#!/bin/bash
MYSQL_USER="..."
MYSQL_PASSWORD="..."

function restore() {
    echo $1;
    (
        echo "SET AUTOCOMMIT=0;"
        echo "SET UNIQUE_CHECKS=0;"
        echo "SET FOREIGN_KEY_CHECKS=0;"
        cat "$1.sql"
        echo "SET FOREIGN_KEY_CHECKS=1;"
        echo "SET UNIQUE_CHECKS=1;"
        echo "SET AUTOCOMMIT=1;"
        echo "COMMIT;"
    ) | mysql -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$1"
}

Con esto aceleramos mucho la inserción, sin embargo de todos modos tarda.

En la página donde saqué estas cosas también vienen otras recomendaciones que pueden ser bastante útiles al exportar e importar Bases de Datos en MySQL.

Cerrar todas las conexiones en Postgresql

A veces queremos hacer una actualización en nuestra base de datos o volver a cargar el dump completo en Postgresql. A mi me pasó de manera local, por alguna razón (que pueden ser muchas) había más conexiones a la base de datos a parte de la que yo actualmente estaba utilizando. Yo quería borrar la base de datos antes de cargar el script del dump, pero Postgres no me permitía indicando que aún había conexiones activas de otros usuarios. Para esto no fue difícil encontrar la solución.

Recuerda tener mucho cuidado con estas sentencias ya que puedes estar cerrando no solo tus propias conexiones sino también las de otros usuarios, en mi caso es solo local, pero puede pasar.

Primero debemos entrar a una terminal psql de la base de datos postgres (no tu base de datos en cuestión porque sino te bota cuando cierras todas las conexiones, incluyendo la tuya acutal):

$psql -h servidor  -U postgres -d postgres

Ahora tecleamos lo siguiente:

postgres=#SELECT pg_terminate_backend(procpid) FROM pg_stat_activity WHERE datname='mi_base_de_datos';

Con esto simplemente eliminamos las conexiones, ahora si podemos hacer una sola conexión para borrar la base de daos y volverla a crear ya sea desde la linea de comandos o usando algún cliente para Postgresql, bueno este fue mi caso, ustedes pueden hacer lo que consideren mejor para su situación :)

A continuación el post completo de referencia, donde se explica a mayor detalle que pasa y algunas alternativas para lo que arriba explicamos. 

Post Original - Araden

Aprovecho para agradecer al autor de este útil post. 

¡¡¡Hasta la próxima Javer@s!!

Case insensitive Mysql: sensibilidad a mayúsculas y minúsculas en MySQL

A continuación incluyo un pequeño artículo donde habla de como MySQL es sensible a mayúsculas y minúsculas en función del sistema operativo que lo esté conteniendo. Como es bien sabido Linux es sensible a mayúsuculas, por lo tanto en un servidor MySQL corriendo en Linux se presentará éste caso. En uno corriendo en Windows al parecer no será así, porque Windows no es sensible a mayúsculas. En el artículo se da una breve descripción del porqué. 

Tuve un problema similar al del artículo utilizando Hibernate con anotaciones en una aplicación Java, donde se nos había ocurrido poner los nombres de tablas con mayúsucula inicial, como por ejemplo: "Usuarios", quienes usábamos Linux tuvimos que resolverlo porque nos creaba por ejemplo la tabla "usuarios" vacía. 

Me voy directo a la manera para resolverlo, transcribiendo del artículo:

Afortunadamente, MySQL contempla el problema. Basta arrancar con mysqld –lower_case_table_names=1 y así cuando creemos cualquier base de datos o tabla, automáticamente la pondrá en minúsculas, haciendo que aparentemente se convierta en "case insensitive". No es totalmente cierto, porque lo que hace en realidad es convertirlo todo a minúsculas.

Aquí el artículo completo. Espero les sea de utilidad:

MySQL: Bases de datos y tablas “case insensitive”

Aprovecho para agradecer al autor, muy recomendable su blog. 

¡Saludos Javer@s!

HSQLDB - HyperSQL

Siguiendo con la linea de herramientas para aplicaciones ligeras, sobre todo para ambientes que se ejecuten de manera embebida, me encontré con este manejador de base de datos: HSQLDB.

HSQLDB es otro manejador de base de datos que esta desarrollado puramente en java. Es un motor de base de datos bastante rápido, una vez que arranca, y bastante versátil y sencillo de usar. Permite conexiones cliente/servidor a través de la red, bases de datos en memoria y bases de datos embebidas. También es un manejador que esta específicamente soportado por Hibernate.

A diferencia de Derby, HSQL trabaja mas en memoria, por lo cual operaciones sobre la base de datos como consultas pueden ser mas rápidas, sin embargo es algo a tener en cuenta cuando se trabaja en bases de datos grandes y se tiene una memoria limitada para la maquina virtual que esta ejecutando el servicio de HSQLDB.

Yo lo he trabajado con Hibernate y se me ha hecho una alternativa muy confiable, de manera embebida trabaja bastante bien. Por otro lado algo que se me ha hecho un poco incomodo es el manejador SQLTool que trabaja de manera nativa con HSQL. Es un interprete de comandos algo rudimentario, así como la interfaz del DatabaseManager hecha en Swing, que también permite hacer consultas a las bases de datos de HSQL. Es muy rustica si las comparamos con otras lineas de comandos y GUI's de manejadores como MySQL, o hasta Postgres por ejemplo, pero es usable.

A continuación algunos enlaces que seguramente te serán de utilidad si tu intención es iniciarte en el uso de HSQL con java:

• Pagina oficial, la cual contiene su respectiva documentación.
• Un Wiki bastante ilustrativo para su uso con java e Hibernate.
• Referencia rápida para su uso con java.

Más adelante publicaré una entrada donde retome algunas comparaciones que se han hecho entre varios manejadores de bases de datos, para que te sea mas fácil elegir alguna alternativa. ¡Paz!

Iniciandose en Derby: Java DB

Derby es un subproyecto de Apache DB. Se trata de un manejador de base de datos de código abierto hecho completamente en java. Derby tiene varias características que lo hacen sumamente atractivo para soluciones en sistemas ligeros. Entre otras me gustaría mencionar las que a mi me llamaron la atención: es fácil de instalar, ligero (pesa tan solo unos cuantos megabytes) y puede usarse de manera embebida (palabra que si existe en español, ver aquí), es decir, que dentro de una aplicación java, podemos iniciar y utlizar bases de datos de Derby dentro de la misma máquina virtua.


Bueno, después de esta pequeña reseña que podemos encontrar fácilmente en cualquier sitio que hable de Derby, vamos a lo importante, como lo usamos dentro de nuestras aplicaciones.

Básicamente lo que haré a continuación será parafrasear un poco los ejemplos de la guía rápida básica de Derby que podemos encontrar en el tutorial oficial.

Primero que nada necesitamos descargar Derby por supuesto, lo cual se puede hacer aquí. Una vez descargado descomprimimos el directorio que esta ahí contenido, ejemplo 'db-derby-alguna_version-bin'. A la ubicación de este directorio lo llamaremos de ahora en adelante: DERBY_HOME.

Comenzaremos con el ejemplo de el uso de Derby embebido dentro de tu aplicación java, lo hago debido a que esta es una de las características que mas llaman la atención de este manejador. Se supone que ya tenemos instalado y debidamente configurado un jdk en nuestro equipo.

Lo haremos a través de la linea de comandos (unix y windows) para hacer mas sencillo de explicar el procedimiento.

Primero creamos un directorio que llamaremos "DERBYTUTOR" y entramos en él. Ahí introduciremos los sguientes comandos, no se te olvide el punto que va al final (.):
Unix:

cp $DERBY_HOME/demo/programs/workingwithderby/* .

export CLASSPATH=$DERBY_HOME/lib/derby.jar:.

 Windows:

copy %DERBY_HOME%\demo\programs\workingwithderby\* .

set CLASSPATH=%DERBY_HOME%\lib\derby.jar;.

Ahora en el directorio DERBYTUTOR en donde nos encontramos deben existir varios archivos java. Después de confirmar que los archivos WwdEmbedded.java y WwdUtils.java existan e introducir el siguiente comando para compilar ambos archivos:

Unix y Windows:

javac WwdEmbedded.java WwdUtils.java

Si en este punto ocurre algún error probablemente es porque no se tiene bien configurado el jdk en nuestro sistema o que al definir el classpath algo no se hizo correctamente.

Si todo salió bien no deberá aparecer nada al ejecutarse la linea anterior y los archivos se habrán compilado satisfactoriamente, creando los archivos WwdEmbedded.class y WwdUtils.class.

A continuación ejecutamos el ejemplo con el siguiente comando y sucederá algo como lo que sigue:

java WwdEmbedded 
org.apache.derby.jdbc.EmbeddedDriver loaded.
Connected to database jdbcDemoDB
 . . . . creating table WISH_LIST
Enter wish-list item (enter exit to end):
a peppermint stick
  __________________________________________________________
On 2009-05-08 13:12:09.058 I wished for a peppermint stick
  __________________________________________________________
Enter wish-list item (enter exit to end):
a long vacation
  __________________________________________________________
On 2009-05-08 13:12:09.058 I wished for a peppermint stick
On 2009-05-08 13:12:21.28 I wished for a long vacation
  __________________________________________________________
Enter wish-list item (enter exit to end):
exit
Closed connection
Database shut down normally
Getting Started With Derby JDBC program ending.

¿Que sucede aquí? Estamos accediendo una base de datos Derby embebida he insertando datos en una tabla. Asi es, sin un servidor Derby activo, simplemente con la aplicación actual.

En el enlace del ejemplo podrás obtener más detalles, lo único que me gustaría comentar aquí es como se logra la conexión en la clase WwdEmbedded a través de que detalles.

Lo único que cambia, con respecto al uso de cualquier JDBC es que utiliza los siguientes parametros:

   // define driver a usar (el contenido en la libreria derby.jar)
      String driver = "org.apache.derby.jdbc.EmbeddedDriver";
   // nombre de la base de datos 
      String dbName="jdbcDemoDB";
   // URL que Derby usara
      String connectionURL = "jdbc:derby:" + dbName + ";create=true";

Y con esto simplemente creamos la conexión de manera normal:

String driver = "org.apache.derby.jdbc.EmbeddedDriver";
...
try {
    Class.forName(driver); 
} catch(java.lang.ClassNotFoundException e) {
  ...
}

String connectionURL = "jdbc:derby:" + dbName + ";create=true";
...
try {
    conn = DriverManager.getConnection(connectionURL);
    ...  
}  catch (Throwable e)  {   
   ...
}

 Aquí concluiría este blog, cualquier otra duda te invito a checar la documentación de los ejemplos, es bastante clara (Aunque en inlgés) y para fines prácticos yo la veo bastante útil.

Puedes ver el sitio oficial de Derby aqui.