Clase que permite transacciones anidadas con PDO

PDO, acrónimo de PHP Data Objects es un interfaz para acceder a bases de datos desde PHP. A diferencia de las extensiones mysql y mysqli, que son exclusivas para MySQL, PDO puede trabajar con diferentes sistemas gestores de bases de datos, siempre y cuando haya driver para el mismo.

Las transacciones sirven para garantizar la integridad referencial de los datos. Una transacción está formada por varias órdenes SQL y bien se ejecutan todas las consultas en bloque o si alguna falla se vuelve al estado inicial antes de empezar la transacción, sin ejecutarse ninguna de ellas. Las transacciones deben cumplir con las propiedades ACID: Atomicidad, Consistencia, Isolation (aislamiento) y Durabilidad. (Nada que ver con el subgénero de música electrónica de finales de los 80 🙂 )

Las transacciones se anidan cuando existiendo una transacción en curso, se inicia otra. Esto por ejemplo sucede cuando desde un método donde se ha iniciado una transacción, para reciclar código (una de las virtudes de la programación orientada a objetos) se llama a otro método que inicia otra transacción.

Transacciones anidadas

Todo fue bien hasta el final y se ejecutan en bloque todas las transacciones (COMMIT)

Transacciones anidadas

¡Ups, algo fallo cuando ya casi finalizaba! ¡Déjalo todo como estaba! (ROLLBACK)

Desgraciadamente, desarrollando en LAMP, nada más iniciarse la segunda transacción se producirá un error fatal. MySQL no soporta las transacciones anidadas. En su documentación afirma que después de ejecutarse un BEGIN TRANSACTION ciertas órdenes producirán un COMMIT, entre ellas BEGIN TRANSACTION. Tampoco las soporta PostgreSQL. Una solución parcial que ambos sistemas incorporan son los SAVE POINTS.

A continuación viene el esquema de una clase que mediante los SAVE POINTS y controlando el número de transacciones anidadas mediante la propiedad transactionDepth, consigue algo parecido a anidar transacciones y por lo tanto evita el error fatal antes mencionado.

Si tu clase extiende la clase PDO, el método execute puede ser reemplazado llamando simplemente a $this->exec() Como digo, esta clase es un esquema para entender la idea, no está pensada para funcionar directamente sino que el programador interesado en ella deberá adaptarla.

class Db { 
  static private $instance = null; 
  private $connection = null;
  protected $transactionDepth = 0; 
 
  private function __construct() { 
  }
  
  private function _connect() { 
     if ($this->connection === null) {
         try {
            /* Código para conectarse a la BD */
         } catch (PDOException $e) {
            echo "error pdo: ";
            echo $e->getMessage();
         }
      }

      return $this;
   }
   
   /* Nada que clonar en el patrón de diseño Singleton */
   private function __clone()
   {
     
   }

   static public function getInstance()
   {
      if (is_null(self::$instance)) {
         self::$instance = new self();
      }

      return self::$instance;
   }

   static public function closeConnection()
   {
      if (!self::$instance === null) {
         self::$instance = null;
      }
      if (isset(self::$connection)) {
         unset(self::$connection);
      }
   }

   public function getConnection()
   {
      $this->_connect();

      return $this->connection;
   }

   protected function prepare($query, $params = array())
   {
      $stmt = $this->getConnection()->prepare($query);
      if (is_array($params)) {
         foreach ($params as $param => $value) {
            if (is_bool($value)) {
               $type = PDO::PARAM_BOOL;
            } elseif ($value === null) {
               $type = PDO::PARAM_NULL;
            } elseif (is_integer($value)) {
               $type = PDO::PARAM_INT;
            } else {
               $type = PDO::PARAM_STR;
            }
            $stmt->bindValue(":$param", $value, $type);
         }
      }

      return $stmt;
   }

   public function execute($sql, $params = array())
   {
      $stmt = $this->prepare($sql, $params);
      $stmt->execute();
      $stmt->closeCursor();

      return $stmt->rowCount();
   }

   public function begin()
   {
      if ($this->transactionDepth == 0) {
         $this->getConnection()->beginTransaction();
      }else{
         $this->execute("SAVEPOINT LEVEL{$this->transactionDepth}");
      }
      $this->transactionDepth++;
   }

   public function commit()
   {
      $this->transactionDepth--;
      if ($this->transactionDepth == 0) {
         return $this->getConnection()->commit();
      }else{
         return $this->execute("RELEASE SAVEPOINT LEVEL{$this->transactionDepth}");
      }
   }

   public function rollback()
   {
      if ($this->transactionDepth == 0) {
         throw new PDOException("Ninguna transacción en curso para retroceder");
      }
      $this->transactionDepth--;
      if ($this->transactionDepth == 0) {
         return $this->getConnection()->rollback();
      }else{
         return $this->execute("ROLLBACK TO SAVEPOINT LEVEL{$this->transactionDepth}");
      }
   }
}

El código también está disponible en Github.

¿Hace falta ir a la universidad para ser un buen desarrollador?

Son muchos los artículos que hay en Internet, principalmente en inglés, defendiendo la idea de que no es necesario ir a la universidad para serlo, llegando algunos al extremo de decir que los mejores desarrolladores son los que no fueron. Las argumentaciones son de lo más variopintas. Algunos razonan que en un mundo teórico ideal el software sería determinista, desarrollado en lenguajes funcionales y por lo tanto libre de efectos secundarios, pero que en el mundo real los lenguajes, por ejemplo Java y todos los orientados a objetos, fueron creados para solventar las necesidades de los negocios, y por lo tanto aceptando que errores del software por casuísticas imprevistas son sobradamente compensados por el incremento en productividad, ductilidad del software, etc. Es decir, que no importa la calidad de la base teórica del software desarrollado, sólo importa si ayuda a cumplir los objetivos de la empresa, que a grandes rasgos sólo pueden ser dos: reducir los costes o aumentar lo beneficios.

Uno de los artículos más famosos que defienden la idea de que no es necesario ir a la universidad, aunque no es este el tema principal del artículo, lo escribió ya hace años Peter Norvig, empleado de Google y de la NASA, reputado científico computacional muy destacado en inteligencia artificial.

Grandes desarrolladores nunca fueron a la universidad o abandonaron a los pocos trimestres: Bill Gates, John Carmack o Jamie Zawinski son buenos ejemplos, Janus Friis no terminó ni el Bachillerato, mientras que buenos ejemplos de lo contrario son Dennis Ritchie, Ken Thompson, Linus Torvalds y Yukihiro Matsumoto.

La informática, en sus albores, fue creada por matemáticos, ingenieros y físicos. A principios del siglo XX se planteó en matemáticas la pregunta: ¿Es posible saber de antemano si un problema matemático tiene solución? Es decir, saber de antemano si hay problemas para los que no hay solución. Los problemas a los que hace referencia la pregunta no son cálculos matemáticos sino afirmaciones, la demostración que concluye si es correcta o no es la solución. Un ejemplo de afirmación es:

Los números primos son infinitos.

La solución es la demostración que concluye si la afirmación es cierta o falsa. Es el llamado problema de la decisión. Lo que el problema pregunta es si es posible saber de antemano si toda afirmación será o bien cierta, o bien falsa, o si existen afirmaciones que no se pueden demostrar.

Cuando el matemático británico Alan Turing creó el modelo matemático que ahora conocemos como máquina de Turing1, no tenía como objetivo crear la computación sino hallar la respuesta a este problema. Por un lado, Turing probó que cualquier método de implementar un problema se podía simplificar siempre a su máquina. Por otro, también probó que no se podía construir ninguna máquina de Turing capaz de demostrar si un problema iba a tener solución o no, por lo que la respuesta al problema de la decisión es un no. Por lo tanto, vemos que el nacimiento de la informática está íntimamente ligado a las matemáticas.

Otro de los padres de la informática, el húngaro John von Neumann, era matemático, ingeniero, físico e inventor. Además de sus aportes para que esta ciencia naciera, aportó a la física, las matemáticas (también a la estadística), la economía y la ingeniería.

Algunos de los desarrollos posteriores que tuvo la ciencia de la computación también fueron debidos a matemáticos y físicos. Unos, para avanzar más en sus respectivas disciplinas, debieron primero avanzar ésta. Otros, directamente dejaron de lado su ciencia para especializarse en la informática.

Creo que está fuera de discusión que la informática es una ciencia cuyas bases están en las matemáticas. Por lo tanto, opino que un conocimiento de la teoría que sustenta la informática, ya sea autodidacta o adquirido en la universidad, da una ventaja a quien lo poseé en un mundo donde la tecnología cambia cada 5 años, donde por ejemplo esas librerías que conocía al dedillo el programador de Visual Basic se convirtieron en conocimiento inútil cuando tuvo que migrar a .NET para no verse tirado en la cuneta por la tecnología. Esta ventaja consiste en la capacidad de aprender más rápido una nueva tecnología. Lamentablemente, a veces un «reclutador» puede preferir a un desarrollador Java recién salido de la universidad frente a otro licenciado años atrás y con experiencia en otro lenguaje pero que quiere migrar a Java, simplemente porque el recién licenciado se sabe más librerías de memoria, lo que frecuentemente sucede en las «cárnicas».

Los conocimientos teóricos no te ponen delante de alguien que lleva años trabajando en el sector, tampoco evitan que te pase la mano por la cara alguien que no los tiene pero sí tiene una elevada inteligencia. Lo único que pueden hacer es hacerte mejor desarrollador y en un mundo global, donde se puede trabajar a distancia para otros países, a veces en otros continentes, tal vez sea más sano no compararse con otros e intentar «sólo» ser mejor. Hace tan sólo 10 años, ser un reconocido desarrollador en Barcelona podía significar unos elevados ingresos, pero hoy una empresa puede contratar los servicios remotos de especialistas a nivel mundial, a sus tarifas, claro.

Otra ventaja, no ya de los conocimientos, sino del título, es que en una empresa muy establecida y grande puede ser una condición sine quan non. Incluso estando el reclutador, por ejemplo el jefe del departamento que necesita el empleado, dispuesto a ver el CV de candidatos sin el título pero con experiencia laboral que considere adecuada, puede verse incapaz de retirar este requisito de la oferta laboral por ser la cultura de la empresa.

Me ha sorprendido haberme encontrado en mi trayectoria profesional compañeros que hacía poco que habían acabado la carrera y afirmaban no entender para qué les habían puesto tantas matemáticas en la carrera: álgebra, análisis, estadística, matemática discreta… O bien pretendían confundirme o bien no entendieron que un ingeniero se las ingenia mejor con una base. En todo caso, tanto esfuerzo de la sociedad para escolarizarlos para que finalmente acabaran llegando a esta conclusión…


1 Este es el modelo que mejor representa un ordenador actual. Como una de sus características es que tiene dos registros capaces de albergar, cada uno, un número entero infinitamente grande, semejante máquina no puede construirse; se trata «sólo» de un modelo teórico.

Anti join

Las bases de datos relacionales (Oracle, SQL Server, Access, MySQL, etc) están basadas en el álgebra relacional. Dicha álgebra la desarrolló el ingeniero británico Edgar F. Codd en 1970 mientras trabajaba para IBM, pero el gigante azul tardó en desarrollar su primera base de datos relacional por preferir seguir explotando los ingresos de su base de datos IMS/DB. Mientras IBM se dedicaba a rentabilizar al máximo su inversión, otras empresas se llevaron el gato al agua al desarrollar sus propios sistemas relacionales a partir de los papeles de Codd. Habían cambiado para siempre las bases de datos.

Codd proporcionó las bases teóricas para las bases de datos relacionales y para los lenguajes que las manipulan. El rey de estos lenguajes es SQL, Structured Query Language. Ahora bien, lo llamo rey por lo extendido que está desde hace décadas, pues curiosamente tiene una carencia importante muy llamativa: no implementa el antijoin que define los papeles de Codd, sin que aparentemente tenga ninguna dificultad su implementación.

Si definimos el semijjoin (el left o right join de siempre) entre dos tablas A y B como:

Es decir, el left semijoin de las tablas A y B es la unión de todos los elementos a que pertenezcan a A junto con al menos uno de b  que pertenezca/n a B y que satisfagan una función sobre a U b. Esta función hace referencia al campo o campos de ambas tablas que hacemos servir para el join, usando sintaxis de MySQL sería

FROM A LEFT JOIN B ON (A.id = B.id)

El antijoin se definiría así:

Es decir, el antijoin de las tablas A y B es la unión de todos los elementos que satisfacen la función sobre a U b a que pertenezcan a A y no pertenezcan a B.

Desgraciadamente SQL no dispone de algo como:

FROM A ANTI JOIN B ON (A.id = B.id)

Y toca ir haciendo apaños como:

FROM A
WHERE A.id NOT IN(
SELECT id
FROM B)

O la supuesta optimización:

FROM A
LEFT JOIN B ON A.id = B.id
WHERE B.id IS NULL

Que producirá resultados inesperados si el campo pivote es nulo en algún registro de B.

Personalmente no veo que sea técnicamente más complicado implementar en los sistemas gestores de bases de datos un antijoin que otros tipos de join, pero el hecho es que de momento ninguno de los sistemas más extendidos lo incorpora en su dialecto SQL.


Editado el 22/01/2020:

En la última versión de MySQL, la 8.0.17, se va a optimizar el «apaño» antes explicado traduciendo la cláusula IN internamente como ANTIJOIN, según se comenta en la documentación. Podemos encontrar más información aquí.

Programa para resolver ecuaciones diofánticas

En el artículo anterior expliqué cómo se resuelven las ecuaciones diofánticas y su relación con las ecuaciones de congruencia. En la presente entrada vamos a ver un programa en Python que las resuelve.

#! /usr/bin/env python
# -*- coding: utf-8 -*-
# Resuelve ecuaciones diofánticas tipo ax + by = c

import sys
from sys import argv

def extendedEuclideanAlgorithm(old_r, r):
    negative = False
    s, old_t = 0, 0
    old_s, t = 1, 1

    if (r < 0):
        r = abs(r)
        negative = True
        
    while r > 0:
        q = old_r / r
        #MCD:
        r, old_r = old_r - q * r, r
        #Coeficiente s:
        s, old_s = old_s - q * s, s
        #Coeficiente t:
        t, old_t = old_t - q * t, t
        
    if negative:
        old_t = old_t * -1
        
    return old_r, old_s, old_t

a = long(argv[1])
b = long(argv[2])
c = long(argv[3])

mcd, s, t = extendedEuclideanAlgorithm(a, b)
if c % mcd == 0:
    a1, b1, c1 = -a / mcd, b / mcd, c / mcd
    x1, y1 = s * c1, t * c1
    print "x = {0}{1:+d}k" . format(x1, b1)
    print "y = {0}{1:+d}k" . format(y1, a1)
else:
    print "No tiene solución"

Para calcuar 23x -4y = 11 hacemos:

vic@LESBIAN:~/mates$ ./diofanticas.py 23 -4 11
x = -11-4k
y = -66-23k

Aplicando el concepto de clase de equivalencia, tal y como se explica en el anterior artículo, podemos computar la forma paramétrica más simplificada como muestra el siguiente programa:

#! /usr/bin/env python
# -*- coding: utf-8 -*-
# Resuelve ecuaciones diofánticas tipo ax + by = c
# El primero par x e y es la forma parmétrica más simplificada
 
import sys
from sys import argv

def extendedEuclideanAlgorithm(old_r, r):
    negative = False
    s, old_t = 0, 0
    old_s, t = 1, 1

if (r < 0):
    r = abs(r)
    negative = True

while r > 0:
    q = old_r / r
    #MCD:
    r, old_r = old_r - q * r, r
    #Coeficiente s:
    s, old_s = old_s - q * s, s
    #Coeficiente t:
    t, old_t = old_t - q * t, t

if negative:
    old_t = old_t * -1

return old_r, old_s, old_t

a = long(argv[1])
b = long(argv[2])
c = long(argv[3])

mcd, s, t = extendedEuclideanAlgorithm(a, b)
if c % mcd == 0:
    a1, b1, c1 = a / mcd, b / mcd, c / mcd
    x1, y1 = s * c1, t * c1
    # Uso abs() pues Python no hace la división Euclídea con cociente negativo
    equivClass = x1 % abs(b1)
    print "x = {0}{1:+d}k" . format(equivClass, b1)
    print "y = {0}{1:+d}k" . format((c1 - (a1 * equivClass)) / b1, -a1)
    print "x = {0}{1:+d}k" . format(x1, b1)
    print "y = {0}{1:+d}k" . format(y1, -a1)
else:
    print "No tiene solución"

Este es el resultado de diferentes ejecuciones:

vic@LESBIAN:~/mates$ ./diofanticas.py 4 7 29
x = 2+7k
y = 3-4k
x = 58+7k
y = -29-4k
vic@LESBIAN:~/mates$ ./diofanticas.py 23 -4 11
x = 1-4k
y = 3-23k
x = -11-4k
y = -66-23k

El uso de la función abs(), que nos devuelve el valor absoluto, es debido a que Python no hace la división Euclídea cuando el cociente es negativo. Los dos pasos:

  • q = old_r / r
  • old_r = old_r – q * r

Se podrían unificar con la función divmod(), pero me parece menos claro para quien no conoce el lenguaje, siendo los dos pasos más parecidos al pseudocódigo.