Cada vez que CakePHP lanza una nueva versión basta con actualizar el directorio cake con los nuevos archivos y (por lo general) todo funciona correctamente. Sin embargo, hay veces en que se producen algunos errores que pueden pasar desapercibidos para los casos de testing y lamentablemente estos bugs llegan a producción. Cuando esto sucede deberemos volver a volver a una versión anterior de CakePHP, hasta tanto encontremos el error y lo solucionemos. Este proceso de rollback puede ser un problema, ya que volver a reemplazar el directorio cake lleva tiempo y los bugs siguen en producción.

Primer intento de solución

Tener varios directorios con el framework, uno llamado cake con la versión actual (que será la que use nuestra aplicación) y otros directorios con las versiones anteriores, por ejemplo cake-1.2.5, cake-1.3.2, etc. De este modo, cada vez que se necesite volver a una versión anterior simplemente se renombran dos directorios.

Esta solución tiene algunos problemas

• Renombrar los directorios es una tarea que tenemos que hacer manualmente, por fuera del proceso de deploy automatizado.
• El core de Cake no es código mantenido por nosotros y por lo general se lo deja fuera del repositorio de nuestra app. Por lo tanto, cada vez que se modifica el directorio cake, tenemos que avisar a todos los miembros de nuestro equipo que hagan lo mismo para que todos trabajemos en iguales condiciones.
• Debemos mantener actualizado nuestro archivo .gitignore para que las nuevas versiones de cake no formen parte del repositorio de Git (o el sistema de versionado que utilicemos).
• Si alguien realiza un checkout de nuestra aplicación no encontrará en el código información acerca de cuál es la versión de CakePHP que necesita para funcionar.

Solución

Crearemos la siguiente estructura de directorios

• app
• cakeversions
  • 1.2.5
    • cake
  • 1.3.2
    • cake

El directorio cakeversions contendrá todas las versiones del core que alguna vez necesitó nuestra aplicación y será ignorada por Git. Los directorios cake dentro de cada número de versión son necesarios ya que el framework requiere que todo el core esté dentro de un directorio llamado exactamente cake.

Después tendremos que modificar el archivo app/webroot/index.php para que tome la nueva ubicación del core. La siguiente línea:

define('CAKE_CORE_INCLUDE_PATH', ROOT);

Debe ser reemplazada por esta:

define('CAKE_CORE_INCLUDE_PATH', ROOT . DS . 'cakeversions' . DS . '1.3.6');

De este modo, cada vez que necesitemos cambiar la versión de cake sólo deberemos modificar el número en esta línea. Los cambios que hagamos se implementarán en producción en el próximo deploy y como el archivo app/webroot/index.php forma parte del repositorio en Git, el resto del equipo lo tendrá actualizado en el próximo fetch o pull que realicen.

Tomemos como ejemplo un modelo Page que cumple con las siguientes condiciones:

• Tiene asociado el TreeBehavior, es decir, cada Page del sistema podría ser hija de otra Page.
• Tiene un campo created en donde se guarda la fecha en que la página fue creada.
• Al momento de mostrar el árbol de páginas quiero que se ordenen por fecha de creación y, si hay dos páginas con la misma fecha de creación, que se ordenen por número de id.

Esto podría conseguirse mediante el siguiente código

$pages = $this->Page->find(
   'threaded',
   array('order' => array('Page.created ASC, Page.id ASC'))
);

Lo cual genera la siguiente consulta

SELECT `Page`.`id`, `Page`.`parent_id`, `Page`.`lft`, `Page`.`rght`, `Page`.`title`, `Page`.`text`, `Page`.`created` FROM `pages` AS `Page` WHERE 1 = 1 ORDER BY `Page`.`created` ASC, `Page`.`id` ASC

Hasta acá todo perfecto, pero si necesitamos generar un listado en forma de árbol para poder usar en un select generado por el Form helper, escribiríamos lo siguiente

$this->Page->generateTreeList();

Que genera la siguiente consulta

SELECT `Page`.`id`, `Page`.`title`, `Page`.`lft`, `Page`.`rght` FROM `pages` AS `Page` WHERE 1 = 1 ORDER BY `Page`.`lft` asc

Como podemos ver el problema es que generateTreeList siempre ordena a través del campo lft y no hay posibilidad de definir un ordenamiento diferente (puedes ver el código aquí)

Intento de solución

Ya que no podemos reordenar los datos al momento de hacer la consulta, intentaremos reordenarlos cuando guardamos las páginas. Para eso, el treeBehavior tiene un método llamado reorder al que podemos pasarle por parámetros cómo queremos que se reordene nuestro árbol. Cada vez que llamamos a reorder, los campos lft y rght del modelo se actualizan automáticamente, de modo que la próxima vez que hagamos un generateTreeList recibiremos los datos ordenados de la forma que queríamos.

El problema con esta solución es que reorder sólo nos permite reordenar a través de un único campo, con lo cual no nos sirve para nuestro ejemplo. Hemos abierto un ticket sugiriendo una pequeña modificación para que nos permita reordenar a través de consultas más complejas, puedes verlo aquí: http://cakephp.lighthouseapp.com/projects/42648/tickets/1263-complex-sort-on-tree-reorder

Solución final

Podemos crear un behavior propio que extienda al treeBehavior oficial y que sobreescriba el método reorder, con las modificaciones que se sugieren en el ticket. De este modo no necesitamos modificar el núcleo de CakePHP.

Uno de los problemas que tienen los UUID es que pueden resultar demasiado largos para algunas aplicaciones. Aquí veremos un método para reducir los clásicos UUID de 36 caracteres a 25.

Supongamos que a cada usuario registrado en nuestro sistema le asignamos un UUID, el cual tenemos que incluir en la url para visualizar su perfil. Esta URL quedaría algo más o menos así:
http://example.com/users/profile/4a3009bd-43f4-4535-ae3e-08a0650df841

Si observamos la composición de un UUID vemos que todos sus caracteres son números hexadecimales (excepto los guiones). Hay muchos caracteres que no están siendo utilizados en esta cadena y si convertimos los números hexadecimales a una base mayor que utilice más caracteres, podríamos reducir la cadena.

PHP tiene una función llamada base_convert que toma tres argumentos: el número a convertir, la base en la que se encuentra dicho número y la base a la cual lo queremos convertir. Si a esta función le pasamos nuestro UUID generado por CakePHP para convertirlo a base 36 (la máxima base que soporta dicha función) y lo pasamos a mayúsculas (sólo para que sea más prolijo), nos queda una cadena de 25 caracteres similar a esta: 4FPTDWER5VQ4G4S408C8O8WO0. La cadena generada sigue siendo única porque el número que representa es el mismo que el UUID original, sólo que está convertido a otra base mayor.

Ahora, para hacer un poco más sencillo el proceso, sería ideal que CakePHP genere automáticamente estos UUID cortos, del mismo modo que los hace con los largos. Si el campo id de una tabla es una cadena de 36 caracteres CHAR(36) o VARCHAR(36), CakePHP genera automáticamente un UUID por cada insert que se hace en la tabla. Con este behavior logramos el mismo comportamiento pero para aquellos campos id que sean cadenas de 25 caracteres. Veamos el código.

<?php

Class ShortUuidBehavior extends ModelBehavior {

	function setup(&$Model, $settings) {
	}

	function beforeSave(&$Model) {
		if(
			empty($Model->data[$Model->alias]['id'])
			and $Model->_schema['id']['length'] == 25
			and $Model->_schema['id']['key'] == 'primary'
			and $Model->_schema['id']['type'] == 'string'
		) {
			$Model->data[$Model->alias]['id'] = $this->_generateShortUUID();
		}
	}

	function _generateShortUUID() {
		$uuid = str_replace('-', '', String::uuid());
		return strtoupper(base_convert($uuid, 16, 36));
	}

}

?>

Este behavior se puede ubicar dentro de app_model.php, ya que sólo afectará a aquellos modelos cuyo id sea una cadena de 25 caracteres.