SQL

WordPress: mejorando el rendimiento con Query Monitor

2020-12-23 - Categorías: General / PHP / WordPress
Logo de WordPress

En la incansable búsqueda por conseguir hacer que las cosas funcionen lo mejor posible, me he encontrado con un plugin que vengo a compartir en este post. Se trata un plugin que todo desarrollador de WordPress debería de conocer, el Query Monitor.

Es un plugin que una vez instalado te muestra detalladamente qué es lo que está pasando dentro de WordPress para poder depurar, mejorar todo y aumentar el rendimiento de la web. Es una manera de tener una visión global del funcionamiento, número de consultas a la base de datos, plantillas cargadas, tiempos, errores/notificaciones/advertencias en la programación, y un largo etcétera..

Continuar leyendo..

Magento 1: sacando ventas por producto más rápido

2018-12-22 - Categorías: Magento
Ventas por producto de Magento

¡Hola de nuevo! Como siempre que puedo, trabajo con Open Source, pues aquí que sigo con la filosofía del Open Source, compartiendo algo más de código fuente Open Source. La verdad es que nunca me planteo alternativas que no sean Open Source, con lo que tengo incluso la obligación de compartir códigos Open Source, ya que tanto me beneficio de los proyectos Open Source, en lo laboral y en lo personal, valga la redundancia.. Se nota que me gusta el Open Source ¿verdad? xDDD

Continuar leyendo..


Magento 1: cómo sacar las ventas por método de pago

2018-01-26 - Categorías: Magento / PHP
Magento ventas por mes y método de pago

Hoy traigo otro code-kata, esta vez para Magento y hecho en PHP. Se trata de un simple script que se lanza en línea de comandos. Con este script obtendremos primero todos los métodos de pago que se han usado al hacer los pedidos. Después, haremos un listado, por método de pago, y entre ciertas fechas, del monto de pedidos completados por método de pago.

Es decir, supongamos que queremos saber cómo han ido las ventas con el método de pago por tarjeta de crédito. O quizá queremos saber si la financiación es un método de pago que funciona bien. O quizá simplemente queremos tener el total de ventas entre fechas.

Pues todo esto es bastante sencillo sabiendo donde está cada cosa.

Métodos de pago usados en pedidos

A saber, los pedidos en Magento 1 guardan parte de sus datos principales en la tabla sales_flat_order. La información del método de pago utilizado en cada pedido se guarda en la tabla sales_flat_order_payment.

Entonces, sacando la columna method de la tabla sales_flat_order_payment tendremos todos los métodos de pago utilizados en los pedidos. Esto en lenguaje SQL queda así:

SELECT distinct(sfop.method)
FROM sales_flat_order_payment sfop
ORDER BY sfop.method ASC;

Ventas de los pedidos enviados

El siguiente paso será saber cómo sacar las cantidades de los pedidos completados. A saber, los pedidos completados se quedan con un status=complete y state=complete. Sí, es raro, Magento tiene internamente dos estados en cada pedido. Uno llamado status y otro llamado state. Estos estados están respectivamente en sus columnas. Así la consulta a la base de datos en SQL para sacar las ventas de un método de pago queda así:

SELECT sum(sfo.grand_total) total_sold
FROM sales_flat_order sfo
JOIN sales_flat_order_payment sfop ON sfop.parent_id = sfo.entity_id
WHERE sfo.state = 'complete' AND sfo.state = 'complete' AND sfop.method LIKE '".$methodCode."'
AND sfo.created_at > '".$startDate->format('Y-m-d H:i:s')."'
AND sfo.created_at < '".$endDate->format('Y-m-d H:i:s')."'"

Fíjate que la tabla sales_flat_order_payment se relaciona con sales_flat_order de la forma que marco en negrita.

El código completo

Ahora bien, haciendo un poco de ejercicio con un par de bucles, programando el script completo, nos queda algo tal que así:

<php

require_once __DIR__.'/app/Mage.php';

Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID);

// Loading arguments.
if ($argc == 3) {
    $yearFrom = $argv[1];
    $yearTo = $argv[2];
} else {
    echo 'ERROR: Incorrect number of arguments.'.PHP_EOL;
    exit;
}

$sqlConnection = Mage::getSingleton('core/resource')->getConnection('core_read');

// Loading available method codes.
$query = 'SELECT distinct(sfop.method)
    FROM sales_flat_order_payment sfop
    ORDER BY sfop.method ASC;';
$methods = $sqlConnection->fetchAll($query);
$methodCodes = array();
foreach ($methods as $method) {
    $methodCodes[] = $method['method'];
}
//var_dump($methodCodes);

// Printing table in CSV format from January to December..
echo 'PAYMENT_METHOD';
for ($year = $yearFrom; $year <= $yearTo; ++$year) {
    for ($month = 1; $month <= 12; ++$month) {
        echo ','.$year.$month;
    }
}
echo PHP_EOL;
foreach ($methodCodes as $methodCode) {
    echo $methodCode;
    for ($year = $yearFrom; $year <= $yearTo; ++$year) {
        for ($month = 1; $month <= 11; ++$month) { 
            $startDate = new DateTime($year.'-'.$month.'-1 00:00:00'); 
            //echo 'Date from: '.$startDate->format('Y-m-d H:i:s').PHP_EOL;
            $endDate = new DateTime($year.'-'.($month + 1).'-1 00:00:00');
            //echo 'Date to: '.$endDate->format('Y-m-d H:i:s').PHP_EOL;

            $query = "SELECT sum(sfo.grand_total) total_sold
            FROM sales_flat_order sfo
            JOIN sales_flat_order_payment sfop ON sfop.parent_id = sfo.entity_id
            WHERE sfo.state = 'complete' AND sfo.state = 'complete' AND sfop.method LIKE '".$methodCode."'
            AND sfo.created_at > '".$startDate->format('Y-m-d H:i:s')."'
            AND sfo.created_at < '".$endDate->format('Y-m-d H:i:s')."'";
            $amount = $sqlConnection->fetchOne($query);
            echo ','.$amount;
        }
        $startDate = new DateTime($year.'-12-1 00:00:00');
        //echo 'Date from: '.$startDate->format('Y-m-d H:i:s').PHP_EOL;
        $endDate = new DateTime($year.'-12-31 23:59:59');
        //echo 'Date to: '.$endDate->format('Y-m-d H:i:s').PHP_EOL;

        $query = "SELECT sum(sfo.grand_total) total_sold
        FROM sales_flat_order sfo
        JOIN sales_flat_order_payment sfop ON sfop.parent_id = sfo.entity_id
        WHERE sfo.state = 'complete' AND sfo.state = 'complete' AND sfop.method LIKE '".$methodCode."'
        AND sfo.created_at > '".$startDate->format('Y-m-d H:i:s')."'
        AND sfo.created_at < '".$endDate->format('Y-m-d H:i:s')."'";
        $amount = $sqlConnection->fetchOne($query);
        echo ','.$amount;
    }
    echo PHP_EOL;
}

Este script tendremos que ponerlo en el directorio raiz del proyecto Magento para que enganche al Magento. Fíjate que necesita de dos parámetros de entrada que son el año de inicio y el año de fin. Además he marcado un objeto que proporciona Magento para estas cosas, la conexión a la base de datos que se guarda en $sqlConnection.

Ejecutando

Guardamos el script anterior en un fichero, por ejemplo llamado script.php. Si queremos las ventas desde el año 2017 al 2017, lo ejecutamos así desde línea de comandos:

$ php script.php 2017 2017

Veremos la salida por pantalla. Ahora bien, si redireccionamos la salida del script a un fichero, luego podremos visualizarlo mejor. Para esto lo ejecutamos así:

$ php script.php 2017 2017 > ventas_por_metodo_de_pago.csv

Ahora abrimos el fichero CSV con nuestro programa de hojas de cálculo favorito para ver los datos. Si no tienes, es muy recomendable el LibreOffice que lo puedes descargar gratis haciendo click aquí.

Así jugando un poco con los datos resultantes, podemos tener una gráfica de evolución de los métodos de pago. Como la imagen de cabecera de arriba. Podemos ver que algo está pasando en abril y por Navidades del año 2017 con uno de los métodos de pago.

Espero que sirva.

Un saludo.


Magento: cambiar scope de los atributos de productos

2016-09-05 - Categorías: Magento
MagentoYelModeloDeDatosEAV

Una de las bondades que tienen Magento es su flexibilidad. En este post vamos a ver el tema de los atributos de producto, cual es su scope o alcance. En general, esto se facilita mucho con su uso interno del modelo de datos EAV. Gracias a EAV que podemos gestionar muchos valores de atributos de cada elemento sin tener que modificar la base de datos. Es decir, no tenemos que hacer una columna nueva para cada atributo nuevo. Sino que se da de alta el atributo en una tabla, y en otra se guardan los valores de los atributos sin haber hecho absolutamente ninguna modificación en la estructura de la base de datos.

Disponemos de tres niveles de configuración normalmente, aunque realmente hay cuatro, para configurar muchas de las cosas que hay dentro de un Magento. Tenemos el nivel de website, de store y de store view. Traducidos son sitio web, tienda, y vista de tienda; y además tenemos el nivel global. Por ejemplo, si vamos a las configuraciones de tiendas podemos tener varios nombres de dominio (uno por website), cada uno con sus configuraciones, plantillas distintas, productos distintos, incluso clientes distintos asignados a cada website o compartidos entre todos los websites. Dentro de un website podemos tener varias tiendas o stores. Y de cada tienda podemos tener varias vistas de tienda, incluso pudiendo cambiar las plantillas o muchas de sus configuraciones de productos, categorías, etc..

El caso de los productos

ProductosChooseStoreView

Volviendo a los productos, primero tenemos que los podemos asignar a cada website. Es decir, un producto puede publicarse en uno de los websites mientras que en otro no. Si vamos al listado de productos nos encontramos en un Magento 1.9 arriba con un desplegable como el de la imagen de al lado, donde podemos configurar los productos a nivel de store view.

Los productos se trabajan al más bajo nivel, al de store view. Esto es así porque el nivel de store view se suele usar para traducir la web. Es decir, publicamos un producto en un website, y configuramos a nivel de vista de tienda cómo lo va a ver el usuario. Si tenemos una vista de tienda por cada idioma, podremos configurar su nombre, descripción, características, etc.. traduciéndolas para cada idioma.

El nivel de los atributos de producto

Podemos dar de alta y configurar nuevos atributos, en la zona de gestión de atributos. Un listado de atributos de ejemplo podría ser tal que así:

Gestión de atributos en Magento

Si el valor del atributo es el mismo en todas las tiendas o vistas de tienda, entonces debería de ser global. Si el valor es distinto, traducible para cada store view, debe de tener el nivel de store view. Es importante saber que todas las etiquetas que se muestran siempre se pueden traducir para cada store view, independientemente de los valores que tome dichos atributos. Es decir, no confundamos las etiquetas que podemos traducirlas con los valores que también podemos traducirlos, no te lleve a confusión.

El atributo de producto ‘status’ es de sistema

Todos los atributos del listado anterior no son de sistema, con lo que no tienen limitación para configurarlos como queramos. Pero los de sistema sí que están limitados. Para este post vamos a trabajar con un atributo que ya viene configurado en Magento que es el estado (status). El estado puede estar habilitado o deshabilitado, y viene configurado a nivel de sitio web. Este atributo puede configurarse para que esté a nivel de website o nivel global. Si lo tenemos a nivel de website entonces podremos habilitar o deshabilitar un producto independientemente en cada website de nuestro Magento.

MagentoGestionAtributosStatus

Esta flexibilidad está bien, pero sólo en ciertos casos. Si tenemos varios websites, de cada uno por lo menos una store, y dentro de cada store podemos tener varias store views para traducir las tiendas.. se puede reducir la cantidad de configuraciones si ponemos el nivel adecuado para cada atributo. Volviendo al caso del atributo status, si me interesa que cuando deshabilite un producto lo haga para todos los websites, entonces debemos de tenerlo a nivel global. De lo contrario, si tenemos 3 sitios web, para estar seguros de que deshabilitamos o habilitamos correctamente el productos en todos los websites deberemos de entrar en la configuración de producto varias veces y comprobarlo.

Así que vamos a ponerlo a nivel global y asegurarnos de que no quedan valores personalizados a nivel de website. Y en tal caso los borramos. Así evitaremos esta excesiva navegación por las fichas de producto. Y así nos aseguramos de que un producto deshabilitado, lo está realmente en todos los websites.

Finalmente, pasando a global el atributo status

Entramos en la configuración del atributo y lo modificamos para que sea global:

MagentoGestionAtributosStatusHaciendoGlobal

Sólo nos falta entrar a la base de datos y, en este caso, borrar todas las configuraciones del atributo a nivel de website que se hayan hecho para que sólo se aplique la configuración global en cada producto. Si se nos quedara en la base de datos algún valor personalizado sin borrar, Magento cogería dicho valor personalizado, en caso de no encontrar valores personalizados de nivel más bajo entonces cogería el valor global.

Encontrando el identificador del atributo

Para esto no tenemos más que entrar a la base de datos e ir a la tabla eav_attribute. Aquí tenemos definidos los atributos que gestionamos en el panel de control. De forma que, tenemos dos columnas con las que identificamos el atributo status: la columna attribute_code, y la columna attribute_id. Aquí buscamos el código que le hemos puesto al atributo, en este caso ‘status’, que no lo hemos creado nosotros porque es de sistema y ya viene configurado.

MagentoGestionAtributosStatusId

Ya hemos encontrado el identificador del atributo, que es el 96. Ahora ya podemos ir a revisar los valores que ha ido tomando el atributo para las distintas vistas de tienda. Para esto vamos a la tabla catalog_product_entity_int que es donde se guardan los ‘valores enteros de los atributos de entidades de productos’ como su nombre indica en inglés.

MagentoGestionAtributosStatusComprobando

Como podemos ver en la imagen, el atributo 96 está cogiendo los valores 1, 2.. para el status el valor 1 es de producto habilitado, el 2 es deshabilitado. Según vemos en la imagen y haciendo un par de consultas podemos ver que la store_id es cero siempre en mi caso. A saber, la store_id cero es el valor del atributo global, es el que coge Magento en caso de encontrar ninguno personalizado. Si tenemos guardados valores distintos para las vistas de tienda, entonces habrían valores con store_id distintos, donde cada store_id corresponde con el identificador de la store.

Cómo listar los stores de una tienda lo cité en el post este, en donde se listan primero los store_id para luego ir recorriendo los productos y asignándolos a todas las stores. Podemos coger aquel script y listar los store_id y así poder editar o simplemente borrar las configuraciones de algunas de las stores.

Borrando valores de atributo personalizados

En este caso, si quisiéramos borrar todas los valores de status personalizados en cada store view bastaría con ejecutar la consulta siguiente y vemos si hay dichos valores personalizados:

SELECT * FROM magento_maxmovil.catalog_product_entity_int
WHERE attribute_id = 96 AND store_id != 0;

Si los hay simplemente modificamos la anterior consulta para borrarlos:

DELETE FROM magento_maxmovil.catalog_product_entity_int
WHERE attribute_id = 96 AND store_id != 0;

Con esto ya nos aseguramos que no vaya a haber problema y hemos pasado el atributo status a scope global. Esto mismo se puede hacer para cualquier otro atributo.

Con esto queda terminado 🙂 otro día más 😉 Un saludo!


Magento: Recuperando contraseñas y el modelo de datos EAV

2015-10-12 - Categorías: General / Magento

Ya estoy de nuevo por aquí frikeando un poco con el software. Estoy en estos días poniéndome al día con Magento. Es la gran solución de Código Libre para trabajar de forma económica montando una web. Entre las tres principales soluciones es la que de momento ostenta la primera posición, la segunda viene a ser Prestashop y la tercera WooCommerce.

Estoy hablando de las soluciones económicas, Open Source, PHP, robustas y estables. Ya si nos centramos sólo en España veremos que el despunte de tiendas online es para Prestashop. Espero no equivocarme con los datos, los puedes comprobar rápidamente haciendo un par de búsquedas y dejar un comentario abajo para corregir.

Situación

Resulta que tenemos entre manos ahora un Magento, pero no podemos entrar al panel de administración que lo tenemos en:

https://nombredominio.com/index.php/admin

Pero sí que tenemos acceso a la base de datos. Es imprescindible tenerlo porque si no entonces tendremos que descartar éste mecanismo de recuperación. Necesitamos entonces acceso mediante phpMyAdmin, Mysql Workbench, línea de comandos..

Dónde tenemos que tocar

Ahora bien, los administradores están en la tabla admin_user y la contraseña de cada uno es la columna password. Si le hemos puesto un prefijo a las tablas entonces la tabla será de la forma prefijo_admin_user. Jeje, parece fácil pero ahora bien ¿qué cifrado se usa en Magento? Pues MD5, y se le añade una semilla al cifrado para hacerlo mejor.

Cómo cifra Magento las claves de administrador

Resumiendo, la estrategia es que pone una semilla delante de la contraseña. Si por ejemplo la semilla va a ser la palabra ‘semilla’ y la contraseña ‘thepass’ lo que hace es cifrar con MD5 la cadena ‘semillathepass’ y luego al resultado le añade después ‘:semilla’ y lo guarda.

Simplemente tenemos que ejecutar lo siguiente que hace esto que explico aquí arriba en el cliente de la base de datos Mysql y tendremos entonces la contraseña cambiada:

UPDATE basededatos.prefijo_admin_user SET password=CONCAT(MD5(‘semillathepass’), ‘:semilla’) WHERE username=’administrador’;

Simplemente ejecutamos esto y se actualizará la clave del administrador ‘administrador’ poniéndole de clave ‘thepass’. Ya lo modificas a tu gusto y a correr 😉

¿Y las claves de usuarios clientes de la tienda?

Ahora bien, vamos a ir un paso más allá. Porque ¿dónde están las claves de los clientes? Éstas las tenemos en la tabla prefijo_customer_entity_varchar, y en prefijo_customer_entity tenemos los valores principales de los usuarios. Y en mi instalación estoy viendo que el atributo de identificador 12 corresponde a las claves de clientes. Que a su vez están cifradas de forma similar a las de administrador.

¿Pero qué tenemos aquí? ¿Porqué tenemos tantas tablas? ¿No sería mas sencillo una supertabla con una fila para cada usuario? Lo que ocurre es que Magento usa el modelo de datos EAV. Es un modelo de datos con el que los atributos que van a tener unos elementos se definen en una tabla, en otras se definen los principales valores de dichos elementos, y los valores disponibles se definen en otra tabla. Esto es engorroso para programar pero proporciona que se puedan definir en ejecución tantos valores como queramos de forma de que no se tengan que modificar ni códigos fuentes ni base de datos. Es muy potente, flexible, pero es engorroso y aumenta la complejidad.. a la hora de tocar base de datos o hacer consultas.

Es muy sencillo verlo de la siguiente forma. Tenemos la tabla de atributos prefijo_eav_attribute, si vemos un listado de algunos atributos podemos tener algo tal que así:

Fíjate que el atributo 12 es el password_hash. Ahora si vamos a los atributos de los customers que tenemos en la tabla prefijo_customer_entity_varchar y vemos los valores de las filas con attribute_id que sea 12 veremos que se parecen a contraseñas como las de los administradores ¿verdad?

Jeje, pues ya tenemos ahí las contraseñas. Parece que tenemos también la semilla después de los dos puntos concatenada con la clave. Será fácil entonces hacer otra consulta que actualice la contraseña de los usuarios de igual manera que la de los administradores.

UPDATE basededatos.prefijo_customer_entity_varchar SET password=CONCAT(MD5(‘semillathepass’), ‘:semilla’) WHERE value_id=1030;

Esta última consulta se supone que modificará la contraseña del cliente con identificador 175, es el valor 1030. A su vez el cliente que tendrá su email en la tabla prefijo_customer_entity y otros datos repartidos por sus tablas correspondientes.

Terminando

Ya lo dejo aquí, con el modelo de datos EAV, que es muy potente, tendremos disponibles todos los datos y podremos andar modificando no sólo las contraseñas de los clientes. Habrá que tener especial cuidado de no sobrecargar de consultas la base de datos, o hacerlo bien optimizándolas con JOINs en vez de concatenando tablas, no creando demasiados bucles que consultan datos y a su vez vuelven a consultar más datos con los resultados, etc.. porque fácilmente podemos relentizar en funcionamiento de nuestro Magento. Pero por otro lado tendremos un sistema muy potente para ir añadiendo lo que necesitemos si crear más y más tablas cada 2 por 3, con el consecuente peligro a la hora de actualizar cuando se añaden tablas o se modifica la base de datos.

Un saludo.


Exportar e importar en MariaDB-MySQL

2015-08-03 - Categorías: General

En estos días he estado haciendo una copia de seguridad de una base de datos compatible con MySQL. En concreto de MariaDB, un ‘replace’ que funciona muy pero que muy bien. Para éste ejemplo he usado un servidor Linux, supongo que en otros sistemas operativos también tendremos disponibles estos comandos.

MariaDB es un fork de la conocida base de datos MySQL que ha seguido más y más desarrollándose e incorporando más y más funcionalidades.

Vamos al grano, es sencillo exportar a un fichero SQL desde línea de comandos con un comando como el siguiente:

$ mysqldump nombreBaseDeDatos -uuser -ppassword > nombreFichero.sql

Lo que hay después de -u es un nombre de usuario, después de -p la contraseña, debe ser un usuario y contraseña válidos y que tengan permiso de acceso a toda la base de datos.

Si queremos hacer pruebas antes de guardar a un fichero el contenido podemos omitir lo último del comando para ver lo que hay en la BD.

$ mysqldump nombreBaseDeDatos -uuser -ppassword

A continuación, si queremos importar el fichero SQL ejecutamos lo siguiente en línea de comandos:

$ mysql nombreBaseDeDatos -uuser -ppassword < nombreFichero.sql

Ya está, es así de sencillo exportar e importar.


Joomla! Platform 3: Bases de datos

2013-06-25 - Categorías: PHP
Ya llegó el calor, terminaron los exámenes de junio y parece que ya llega el verano, aunque hace poco aún estaba lloviendo en la costa mediterránea de España. Yo sigo con lo mío y hoy les traigo un acceso a bases de datos usando SQLite, una base de datos de dominio público, embebida, no necesita instalación y simplemente con que PHP tenga activada la extensión para ello ya podemos usarla.
Como viene siendo costumbre de la serie que escribo, me voy a centrar en el uso en un servidor web, con lo que el ejemplo es una página web. Se puede también ejecutar en línea de comando pero yo no uso PHP de esa forma así que… vamos al grano.


Materiales

  1. El framework Joomla Platform. Yo he usado la versión 12.3, la oficial veo que es la 12.1 y está en desarrollo la 13.1. Aquí hay más información para los curiosos como yo.
  2. Un entorno de desarrollo. Aquí ya para gustos estan los colores, Eclipse va muy bien y es multiplataforma.
  3. Un servidor para ejecutarlo. XAMPP funciona muy bien y también es multiplataforma.

Empezando

Descomprimo el framework en el directorio si es que no lo tengo ya, entonces hay que crear un fichero .php como en el ejemplo siguiente y veremos rápidamente como funciona:
...
<?php

// se importa la Plataforma Joomla.
require_once 'libraries/import.php';

class laWeb extends JApplicationWeb {
protected function doExecute()
{
$this->setBody("<html><body>");
$this->appendBody("<h1>Plataforma Joomla! SQLite</h1>");

// vector de configuración de la base de datos
// para sqlite sólo hace falta ésto
$option = array();
$option['driver'] = 'sqlite'; // tipo de bd
//$option['host'] = 'direccionhost.com'; // host
//$option['user'] = 'usuario'; //
//$option['password'] = 'contraseña'; //
$option['database'] = 'bdpruebas.sqlite'; // nombre de la bd
//$option['prefix'] = 'pref_'; // prefijo
$dbo = JDatabaseDriver::getInstance($option);

// se puede abreviar usando:
//$dbo = JDatabaseDriver::getInstance(array('driver' => 'sqlite', 'database' => 'bdpruebas.sqlite'));


// crea una tabla para las pruebas, la borra si existe
$dbo->setQuery("DROP TABLE IF EXISTS aleatorios");
$dbo->execute();
$dbo->setQuery('CREATE TABLE IF NOT EXISTS aleatorios (id INTEGER PRIMARY KEY, numero INTEGER)');
$dbo->execute();
$this->appendBody("<p>Creada la base de datos...</p>");

// inserta unos datos en la BD
for ($i = 0; $i < 10; $i++) {
$dbo->setQuery('INSERT INTO aleatorios (id, numero) VALUES (' . $i . ', ' . rand(0,99) . ');');
$dbo->execute();
}
$this->appendBody("<p>Insertados datos...</p>");

// lee la tabla
$this->appendBody("Listando con loadRowList ");
$dbo->setQuery("SELECT * FROM aleatorios;");
$resultados = $dbo->loadRowList();
foreach ($resultados as $res){
$this->appendBody( "<p>" . $res[0] . ", " . $res[1] . "</p>");
}

// lee la tabla de otra forma
$this->appendBody("Listando con loadAssocList ");
$dbo->setQuery("SELECT * FROM aleatorios;");
$resultados = $dbo->loadAssocList();
foreach ($resultados as $res){
$this->appendBody( "<p>" . $res['id'] . ", " . $res['numero'] . "</p>");
}

// lee de nuevo la tabla de otra forma
$this->appendBody("Listando con loadObjectList ");
$dbo->setQuery("SELECT * FROM aleatorios;");
$resultados = $dbo->loadObjectList();
foreach ($resultados as $res){
$this->appendBody( "<p>" . $res->id . ", " . $res->numero . "</p>");
}

$this->appendBody("</body></html>");

}
}

JApplicationWeb::getInstance("laWeb")->execute();
...

El ejemplo en descarga está aquí.

El resultado de ejecutarlo desde el navegador debe ser algo tal que así:

Plataforma Joomla! SQLite

Creada la base de datos…
Insertados datos…
Listando con loadRowList
0, 55
1, 4
2, 1
3, 76
4, 95
5, 62
6, 63
7, 16
8, 52
9, 73
Listando con loadAssocList
0, 55
1, 4
2, 1
3, 76
4, 95
5, 62
6, 63
7, 16
8, 52
9, 73
Listando con loadObjectList
0, 55
1, 4
2, 1
3, 76
4, 95
5, 62
6, 63
7, 16
8, 52
9, 73

Explicaciones

Lo que hace el programa es crear el archivo bdpruebas.sqlite si no existe, es un comportamiento peculiar de SQLite. Si usásemos otra base de datos como PostgreSQL o MySQL podríamos usar las sentencias SQL propias de cada base de datos. El código usa las funciones para cargar tablas de datos loadRowList, loadAssocList y loadObjectList. Ésto nos devuelve un objeto que almacenará los datos de la base de datos en nuestro programa. Hay otras funciones para cuando la consulta devuelve sólo una fila o sólo un dato por ejemplo.
Hasta aquí todo bien, pero entonces ¿porqué usar el framework y no usar directamente PHP como siempre sin framework?
Ahora a partir de las últimas versiones se han añadido más bases de datos aparte de la original MySQL, tenemos PostgreSQL, SQLServer, y se preveen el acceso a muchas otras. Ahora bien, tenemos una capa extra que nos va a independizar totalmente de la base de datos, siempre que no usemos las tradicionales sentencias SQL, como en el ejemplo anterior, y construyamos nuestra aplicación usando ésta herramienta. Puede que en un futuro querramos cambiar de base de datos o hacer posible que dicho cambio sea dinámico según configuración del usuario.

Independizando de la base de datos

La historia está en crear la query usando el framework. Tenemos la clase JDatabaseDriver que es la que nos provee de la conexión a la base de datos. Ahora sí, contruimos la $query usando la clase JDatabaseQuery y entonces obtendremos esa compatibilidad de las consultas, inserciones, actualizaciones y borrados de nuestro programa con varios tipos de bases de datos. He simplificado el ejemplo anterior:
...
<?php

// se importa la Plataforma Joomla.
require_once 'libraries/import.php';

class laWeb extends JApplicationWeb {
protected function doExecute()
{
$this->setBody("<html><body>");
$this->appendBody("<h1>Plataforma Joomla! Independizando de la base de datos</h1>");

//
$dbo = JDatabaseDriver::getInstance(array('driver' => 'sqlite', 'database' => 'bdpruebas.sqlite'));

// borrando los datos de la tabla aleatorios
// para tenerla limpia
$query = $dbo->getQuery(true);
$query->delete('aleatorios');
$dbo->setQuery($query);
$dbo->execute();

$this->appendBody("<p>Borrados los datos...</p>");

// inserta unos datos en la BD
for ($i = 0; $i < 10; $i++) {
// crear una nueva consulta
$query = $dbo->getQuery(true);

// se construye
$query->insert('aleatorios')
->columns('id, numero')
->values($i . ', ' . rand(0,99));

// se establece
$dbo->setQuery($query);

// se ejecuta
$dbo->execute();
}
$this->appendBody("<p>Insertados datos...</p>");

// consultado datos
$query->select('*')->from('aleatorios');
$dbo->setQuery($query);
$resultados = $dbo->loadObjectList();
foreach ($resultados as $res){
$this->appendBody( '<p>' . $res->id . ', ' . $res->numero . '</p>');
}

$this->appendBody("</body></html>");

}
}

JApplicationWeb::getInstance("laWeb")->execute();
...

Éste segundo ejemplo está en descarga aquí.

Utilizando la base de datos creada con el primer ejemplo, si guardamos éste segundo en otro fichero .php y lo ejecutamos en el navegador funcionará de forma similar. Ahora, si tenemos la base de datos distinta de SQLite, simplemente con cambiar la línea:
$dbo = JDatabaseDriver::getInstance(array('driver' => 'sqlite', 'database' => 'bdpruebas.sqlite'));
Haciendo la conexión con la base de datos que tengamos, nos aseguramos que el resto de consultas, inserciones, actualizaciones o borrados van a funcionar.

Terminando

Otra vez más, me remito para más información a la documentación oficial:

http://docs.joomla.org/J3.1:Accessing_the_database_using_JDatabasehttp://api.joomla.org/Joomla-Platform/Database/JDatabaseQuery.html#insert

Éste post al final se ha hecho bien largo, ¡otro testamento! xDD Es que las bases de datos lo merecen ¿no cree?

Espero que sirva.
Saludos.


SQLite con Java

2013-03-07 - Categorías: General

Hoy les dejo un acceso a una base de datos SQLite, que últimamente está tan de moda. SQLite se usa en todo tipo de programas, es de dominio público, se puede incluir en tu programa añadiendo alguna librería muy ligera, y te da casi todas las funcionalidades que te puede dar cualquier otra BD relacional (de las que usan SQL).

Materiales

  1. Una vez más, mi entorno de desarrollo favorito, el Eclipse que supongo ya instalado. También se puede seguir el post usando otro entorno http://www.eclipse.org/
  2. Una librería hecha por completo en Java para usar SQLite, un tal Taro L. Saito, de Xerial nos deja en su repositorio para descargar en https://bitbucket.org/xerial/sqlite-jdbc/downloads
  3. El JDK instalado http://www.oracle.com/technetwork/java/javase/downloads/index.html 

 Un poco de teoría

Lo que he averiguado en mis investigaciones, más que nada con lo que me han explicado amigos, es que SQLite lo que no tiene son claves ajenas, con lo que la integridad referencial no está implementada dentro de su llamemosle «motor de la BD» es que tenemos integridad referencial, claves ajenas. Se pueden usar disparadores (triggers), cuando se hagan inserciones, modificaciones o borrados. Podemos usar BLOBs, definir los tipos de datos de las tablas, y un largo etcétera…

Según pone en la Wikipedia http://es.wikipedia.org/wiki/SQLite, la versión 3 de SQLite admite archivos de 2 Terabytes con incluso tipos de datos BLOB, con lo que podemos almacenar ficheros dentro de la base de dato. Con ésto creo que tenemos bastante, por lo menos para empezar a trastear las BD sin tener que instalar todo un señor motor de BD como los de Oracle o MS SQL Server, o los que más me gustan a mi como PostgreSQL o Firebird. En Java funcionan todas éstas BD de manera parecida, la idea principal es usar el JDBC que proporciona un estándar de conexión para conexión a bases de datos desde Java.

Manos a la obra

Al grano, después de un poco de teoría, antes de empezar con el código, hay que preparar el proyecto en Eclipse:

  1. Creo un nuevo proyecto de Java.
  2. Copio la librería de SQLite, en el proyecto, Eclipse te deja coger y arrastrar el fichero al Explodor de Proyectos con lo que te proguntará si quieres copiar o hacer un enlace externo al fichero. Prefiero copiarlo dentro del proyecto porqué así siempre estará incluido si es que creamos un ejecutable o nos llevamos el proyecto a otro ordenador.
  3. No basta con copiar la librería, tenemos que agregarla al Build Path del proyecto. Con el botón derecho del ratón en el explorador de proyectos, le damos a Build Path > Configure Build Path… Le damos a Add JAR… y elegimos el fichero que ya está dentro del proyecto. Debes ver una ventana parecida a ésta:

Hecho ésto ya podemos usar la librería desde cualquier clase que creemos dentro de éste proyecto. Entonces ya sí que sí, que empezamos creando una nueva clase, con un main. Yo he usado el generador de código de Eclipse y me ahorro tiempo. Entonces el código de ejemplo con el que se crea un fichero bdpruebas.db, luego dentro crea una tabla llamada tablapruebas, y va insertando valores aleatorios del 1 al 100 con un índice. Queda así:

package SqlitePack;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;

public class ProbandoSqlite {

public static void main(String[] args) throws ClassNotFoundException {

Class.forName("org.sqlite.JDBC");

try {

// ESTABLECER LA CONEXIÓN
Connection conexion;
conexion = DriverManager.getConnection("jdbc:sqlite:bdpruebas.db");

// CREAR ENUNCIADO
Statement enunciado;
enunciado = conexion.createStatement();

// CREAR UNA TABLA NUEVA, LA BORRA SI EXISTE
enunciado.execute("DROP TABLE IF EXISTS tablapruebas;");
enunciado.execute("CREATE TABLE tablapruebas (id int primary key, aleatorio int);");

// INSERTAR DATOS
for (int i = 1; i <= 100; i++) {
enunciado.execute("INSERT INTO tablapruebas (id, aleatorio) values ("
+ i
+ ", "
+ Math.floor(Math.random() * 100 + 1) + ");");
}

// CONSULTA DATOS
ResultSet resultados;
resultados = enunciado.executeQuery("SELECT * FROM tablapruebas;");

// PROCESAR EL RESULTADO
while (resultados.next()) {
System.out.println("id " + resultados.getString(1)
+ ": aleatorio " + resultados.getString(2));
}

// CERRAR
resultados.close();
enunciado.close();
conexion.close();

} catch (Exception e) {
System.out.println("ERROR: " + e.getMessage());
}

}

}

Lo que hace el código es crear tres objetos: conexión, enunciado y resultados. Con conexión como su nombre indica, nos conectamos a la base de datos, si el fichero no existe lo crea, ésto es un comportamiento propio de SQLite. Con el enunciado lo que venimos a tener es una especie de «mesa de trabajo» con lo que vamos a atacar la base de datos con todo tipo de consultas o sentencias SQL. Es interesante el PreparedStatement para mejorar el funcionamiento interno de nuestro programa pero eso es otro tema. Luego con el objeto resultados en éste ejemplo lo que se hace es almacenar los resultados de la consulta.

Las sentencias SQL que se han usado lo que hacen es borrar la tabla si existe, la crean y llenan la tabla con los INSERT INTO. La última consulta con el SELECT lo que hace simplemente es listar todos los resultados de la tabla.

Dejo el proyecto en descarga como viene siendo costumbre xD

Descargar

Terminando

Para terminar, si pulsamos F11 en la ventana de consola debemos ver en los resultados algo tal que así:

id 1: aleatorio 4
id 2: aleatorio 70
id 3: aleatorio 94
id 4: aleatorio 40
id 5: aleatorio 86
id 6: aleatorio 40
id 7: aleatorio 89
id 8: aleatorio 80
id 9: aleatorio 79
id 10: aleatorio 14
id 11: aleatorio 69
id 12: aleatorio 2
id 13: aleatorio 12
id 14: aleatorio 62
id 15: aleatorio 74
id 16: aleatorio 53
id 17: aleatorio 45
id 18: aleatorio 44
id 19: aleatorio 56
id 20: aleatorio 40
id 21: aleatorio 81
id 22: aleatorio 75
id 23: aleatorio 97
id 24: aleatorio 78
id 25: aleatorio 63
id 26: aleatorio 30
id 27: aleatorio 13
id 28: aleatorio 21
id 29: aleatorio 68
id 30: aleatorio 58
id 31: aleatorio 25
id 32: aleatorio 92
id 33: aleatorio 88
id 34: aleatorio 77
id 35: aleatorio 38
id 36: aleatorio 45
id 37: aleatorio 18
id 38: aleatorio 47
id 39: aleatorio 60
id 40: aleatorio 51
id 41: aleatorio 90
id 42: aleatorio 90
id 43: aleatorio 96
id 44: aleatorio 34
id 45: aleatorio 47
id 46: aleatorio 89
id 47: aleatorio 97
id 48: aleatorio 58
id 49: aleatorio 78
id 50: aleatorio 49
id 51: aleatorio 23
id 52: aleatorio 82
id 53: aleatorio 12
id 54: aleatorio 92
id 55: aleatorio 51
id 56: aleatorio 99
id 57: aleatorio 56
id 58: aleatorio 9
id 59: aleatorio 14
id 60: aleatorio 1
id 61: aleatorio 4
id 62: aleatorio 80
id 63: aleatorio 80
id 64: aleatorio 97
id 65: aleatorio 89
id 66: aleatorio 47
id 67: aleatorio 3
id 68: aleatorio 73
id 69: aleatorio 34
id 70: aleatorio 99
id 71: aleatorio 22
id 72: aleatorio 38
id 73: aleatorio 69
id 74: aleatorio 22
id 75: aleatorio 6
id 76: aleatorio 97
id 77: aleatorio 28
id 78: aleatorio 47
id 79: aleatorio 21
id 80: aleatorio 50
id 81: aleatorio 89
id 82: aleatorio 22
id 83: aleatorio 71
id 84: aleatorio 98
id 85: aleatorio 45
id 86: aleatorio 20
id 87: aleatorio 12
id 88: aleatorio 29
id 89: aleatorio 75
id 90: aleatorio 11
id 91: aleatorio 54
id 92: aleatorio 24
id 93: aleatorio 86
id 94: aleatorio 89
id 95: aleatorio 90
id 96: aleatorio 39
id 97: aleatorio 34
id 98: aleatorio 1
id 99: aleatorio 37
id 100: aleatorio 66

Ya les dejo con ésto, espero que a alguien le sirva, un saludo.

© 2024 JnjSite.com - MIT license

Sitio hecho con WordPress, diseño y programación del tema por Jnj.