Para aquellos que les interesa las conferencias, en Noviembre 2008, php|works 2008 es una de las mejores conferencias en el calendario de PHP. Organizada por los editores de php|architect, en esta edición además agrega charlas de Python.

Más información.

Luego de mucho tiempo de desarollo, Symfony 1.1 fue presentado y está listo para ser usado.

Aquí está el link del anuncio.

Es importante leer el documento que explica como “upgradear” proyectos de 1.0.

El mismo dia, también fue lanzado Symfony 1.0.17.

Symfony permite utilizar distintos medios para guardar los datos de sesión. Por defecto, Symfony utiliza el sistema de archivos (con el directorio /tmp)

Para correr Symfony en un cluster de servidores web es necesario guardar la sesión en un lugar centralizado. Para esto se puede utilizar Mysql.

Es necesario crear una tabla para guardar los datos. El schema es el siguiente:

CREATE TABLE IF NOT EXISTS `session` (
`id` VARCHAR(32) NOT NULL ,
`sess_time` INT NULL ,
`data` TEXT NULL ,
PRIMARY KEY (`id`) )

Luego, hay que configurar Symfony para utilizar esta tabla. Primero, debemos crear la conexión a la base de datos para la sesión . En el archivo config/databases.yml ponemos:

session:
class: sfPDODatabase
param:
dsn: mysql:dbname=mydb;host=localhost
username: myuser
password: mypass

Recuerden reemplazar los datos de dbname, host, username, y password con sus datos de conexión.

Luego, en la configuración de la aplicación es necesario definir la clase para guardar la sesión utilizando PDO. En el archivo config/factories.yml de la aplicación debemos agregar lo siguiente:

all:
class: sfPDOSessionStorage
param:
db_table: session
database: session
session_name: session
db_id_col: id
db_time_col: sess_time
db_data_col: data

Luego de limpiar el cache con symfony cc la sesión deberia ser guardada en la tabla.

También es posible utilizar la conexión de propel existente, pero al momento de escribir este artículo tengo algun problema con este método. Luego comentaré la solución.

Links para más información:

• http://www.symfony-project.org/snippets/snippets/tagged/session/order_by/date
• http://www.symfony-project.org/book/1_0/06-Inside-the-Controller-Layer#User%20Session

Si utilizas propel para generar el sql desde el schema, y necesitas que incluya el tipo innodb en la declaración de creación de la tabla, debes incluir la siguiente línea en /config/propel.ini :

mebelipropel.mysql.tableType = InnoDB

Luego, ejecutando “symfony propel-build-sql” generará el archivo .sql en data/sql con el correspondiente tipo.

Al momento de crear algunas tablas en el modelo de datos, para algunos índices elegí el tipo de datos BIGINT de Mysql.

Luego de convertir el modelo a un schema.yml con propel, y generar un admin con propel-init-admin descubrí que el sorting usando columnas que son BIGINT no estaba correcto. El orden era calculado usando strings en vez de números.

Así fue como descubrí que propel convierte BIGINT a strings y no INT.

Para solucionar el problema, hay que reemplazar BIGINT por INTEGER y generar el modelo nuevamente.

Si no lo sabes, MySQL no tiene tipo de datos BOOLEAN como otras RDBMS. Cuando uno crea una tabla con columnas BOOLEAN, estas son creadas como TINYINT.

Por su parte, Symfony tiene un feature muy bueno: cuando uno crea un admin basado en un modelo, si encuentra una columna BOOLEAN, lo presenta con un checkbox, pero si es TINYINT pone un INPUT TEXT.

Como a mi me gusta generar el modelo usando el MySQL Workbench cuando genero el schema para el symfony utilizando la base de datos creada, symfony encuentra la columna como TINYINT.

Para resolver esto, utilizo el comando sed para hacer el reemplazo en un script de bash:

#!/bash/sh

symfony clear-cache

symfony propel-build-schema

mv config/schema.yml config/schema_bak.yml

sed s/TINYINT/BOOLEAN/ config/schema_bak.yml > config/schema.yml

symfony propel-build-model

Al utilizar foreign keys, podemos relacionar distintos objetos. Por ejemplo, si tenemos un mensaje, y dicho mensaje tiene un destinatario, al listar los mensajes podemos listar el nombre del destinatario en vez de su id.

Luego de generar el admin con symfony propel-init-admin, editando el archivo generator.yml del modulo en cuestión:

list:
peer_method: doSelectJoinDestinatario
display: [mensaje, destinatario]

Recientemente he estado comentando sobre Zend Framework. Este proyecto se ha convertido en muy poco tiempo en algo muy importante para el desarrollo de aplicaciones web, y creo que seguirá creciendo en calidad y cantidad de features.

Pero hace unas semanas comencé un proyecto con una base de datos con muchas tablas, que requiere de un sistema de administración completo. A esta altura, lo que menos me gusta de desarrollar aplicationes web es el trabajo monótono y repetitivo de crear listas y forms para un backend. El Zend Framework todavia no tiene todos los utilitarios para la generación de código, ya sea de objetos relacionados con el modelo (las tablas) o menos aún la generación automática de un sistema de administración de dicha información.

El framework Symfony si lo tiene. Por este motivo, estas ultimas semanas estuve introduciendome a dicho proyecto, que por cierto, tiene una madurez y una calidad considerable, no por nada Yahoo lo eligió para alguno de sus sistemas.

Gracias a esto, ire comentando alguna de mis experiencias con Symfony, algunas serán muy basicas y otras no tanto. Espero sus comentarios.

Hace poco comence un nuevo proyecto que contiene muchas tablas en la base de datos. Para hacer la vida un poco más fácil, decidí usar el Mysql Workbench.

Este utilitario permite diseñar bases de datos y tablas visualmente. Una vez terminado, se puede exportar el resultado a SQL para crear todas las tablas.

Una de las opciones más interesantes es que permite relacionar tablas usando foreign keys. Luego de crear unas cuantas tablas, al correr el SQL en el servidor, algunas tablas no eran creadas y obtenía el siguiente error:

Can’t create table errno: 121

Buscando en google encontre varias menciones pero nada concreto hasta que, finalmente, di en el clavo. El nombre de las relaciones son asignadas automáticamente por el programa (se pueden cambiar si es necesario/deseado), resulta que algunas relaciones tenian el mismo nombre. Fue cuestión de cambiar el nombre en la definición de la relación y listo.

Problema solucionado, pero me tomó un buen rato encontrar el significado de este error, no muy bien documentado.