Lo que hay que ver…

SELECT ji.title AS title,
(SELECT name FROM jos_sobi2_categories jc WHERE
jc.catid = jr.catid) as provincia,
(SELECT data_txt FROM jos_sobi2_fields_data WHERE fieldid='1'
AND itemid=ji.itemid) AS direccion,
(SELECT data_txt FROM jos_sobi2_fields_data WHERE fieldid='2'
AND itemid=ji.itemid) AS cp,
(SELECT data_txt FROM jos_sobi2_fields_data WHERE fieldid='3'
AND itemid=ji.itemid) AS localidad,
(SELECT data_txt FROM jos_sobi2_fields_data WHERE fieldid='4'
AND itemid=ji.itemid) AS localidad2,
(SELECT data_txt FROM jos_sobi2_fields_data WHERE fieldid='7'
AND itemid=ji.itemid) AS email,
(SELECT data_txt FROM jos_sobi2_fields_data WHERE fieldid='8'
AND itemid=ji.itemid) AS web,
(SELECT data_txt FROM jos_sobi2_fields_data WHERE fieldid='10'
AND itemid=ji.itemid) AS telefono,
(SELECT data_txt FROM jos_sobi2_fields_data WHERE fieldid='11'
AND itemid=ji.itemid) AS fax
FROM jos_sobi2_item ji
INNER JOIN jos_sobi2_cat_items_relations jr
ON ji.itemid = jr.itemid

Select que te select, con más select y algún que otro select… ¡poum!

Optimi… ¿qué?

El día 27 Oracle presentó en un evento multitudinario lo que van a ser en lineas más o menos generales sus prioridades de y lineas de negocio para los próximos meses tras la compra de Sun Microsystems. En Java Hispano hicieron una gran cobertura de la retransmisión y se pueden leer sus impresiones en el siguiente artículo.

Dos cosas que personalmente no me han sorprendido en absoluto:

• Su deseo de seguir potenciando Java (aunque no dijesen mucho de JavaFX): Está claro que no van a dejar de lado uno de los lenguajes y tecnologías más utilizados en este momento. Tampoco van a hacer cambios drásticos por temor a que los desarrolladores migren de plataforma.
• MySQL, que estoy seguro que ha sido parte del acuerdo con la U.E., seguirá siendo desarrollado, y en el fondo de la cuestión, creo que a Oracle le interesa. MySQL y Oracle nunca han jugado en la misma liga ni se enfocan al mismo mercado, y ahora Oracle tiene dos mercados distintos que dominan. ¿Por qué iban a abandonar uno de ellos?

Aunque parezca dificil de creer, a lo que le veo peor futuro es a Oracle XE, creo que ese nicho de mercado lo van a potenciar con MySQL y crearán de alguna forma una opción de migración rápida entre este último motor de base de datos y su producto estrella, Oracle.

En el lado muy negativo, veo un futuro muy negro tanto para Glassfish como para mi querido Netbeans, del cual ya han dejado claro que su desarrollo no va a ser prioritario, y por ende, dejará de poder competir codo con codo con Eclipse. Me parece una noticia muy negativa, sobre todo para alguien que, como en mi caso, utiliza Netbeans a diario.

Esto ha sido lo “oficial”, en los próximos meses veremos si todo es verdad o entre líneas se escondían otras sorpresas completamente inesperadas.

Probablemente cualquier persona que habitualmente programe en Java conocerá el sistema Log4J, el sistema de log de eventos más utilizado en esta tecnología. Aunque este post no pretende ser ninguna introducción dado que estas ya existen, si quiero destacar el alto nivel de flexibilidad que ofrece el sistema, en especial en los ámbitos de “salida” (appender) de la información y en el “formato” (pattern) que se le da a la misma.

Personalmente me he encontrado en muchas ocasiones ante ficheros de log que eran muy difíciles de seguir… bueno, creo que ningún fichero con mucho contenido es fácil de “parsear” manualmente. De esta problemática llega el motivo del post, la necesidad de organizar la salida de forma que pueda ser fácilmente ordenada y fácilmente consultada a posteriori: esto es, una base de datos.

Log4J, gracias a su flexibilidad, permite incorporar una salida directa a una base de datos… por lo que matamos dos pájaros de un tiro: en una aplicación que ya utiliza Log4J, no tendremos que realizar ninguna modificación en el código, tán solo las siguientes líneas de código en el fichero de configuración (por ejemplo, log4j.properties).


log4j.rootCategory=INFO, FILE, BD


log4j.appender.BD=org.apache.log4j.jdbc.JDBCAppender
log4j.appender.BD.URL=jdbc:mysql://localhost/base_de_datos
log4j.appender.BD.user=root
log4j.appender.BD.password=root
log4j.appender.BD.sql=INSERT INTO nombre_table (Fecha, Clase, Nivel, Mensaje) VALUES ('%d', '%c', '%p', '%m')


En este caso, estamos indicando que filtraremos a partir del nivel INFO (es decir, no se guardarán los TRACE ni DEBUG) y lo haremos en un appender FILE y en el apprender BD cuya configuración es muy sencilla, la misma que para cualquier conexión a una base de datos MySQL. Por supuesto podremos utilizar cualquier BD con soporte JDBC. La query SQL también puede ser modificada, en esta incluyo los parámetros habituales en columnas separadas.

En la documentación de Log4J se incluyen todos los parámetros que pueden ser incluídos.

Dedicaré un futuro post a hablar de como extender Log4J para incluir otras opciones además del propio mensaje, en mi caso en particular, poder grabajar en una columna separada el ID del elemento que daba el “warning”.

La noticia económica e informática del día, del mes… y a saber si del año. Cuando todo el mundo hablaba de la “más que posible” compra de Sun por parte de IBM ha llegado Oracle y se la ha comido. Aunque ya apuntaba maneras, ahora si que se puede decir que Oracle se ha convertido en una de las grandes, y será de las grandes por el hecho de manejar conjuntamente tres tecnologías base actualmente: Java, MySQL y el propio Oracle.

Ayer se escuchaban voces que temian por el futuro de Java y MySQL tal y como los conocemos. Sinceramente, no creo que vaya a ocurrir nada malo. Java es la base de las aplicaciones de Oracle por lo que su desarrollo como lenguaje no se va a ver mermado. En cuanto a MySQL… no es competencia de Oracle, nunca lo ha sido, por lo que seguirá tal cual, y espero que su desarrollo como mínimo al mismo nivel.