IBlog » Uso de múltiples bases de datos en Symfony con Propel y Organizar el modelo en una estructura de subpaquetes

Inicio > Herramientas varias, Symfony > Uso de múltiples bases de datos en Symfony con Propel y Organizar el modelo en una estructura de subpaquetes

Uso de múltiples bases de datos en Symfony con Propel y Organizar el modelo en una estructura de subpaquetes

Jueves, 7 de Enero de 2010 Henry Vallenilla Dejar un comentario Ir a comentarios

A continuación, explicaré como organizar mi PROJECT_DIR/config/databases.yml para múltiples conexiones.

   all:
     propel:
       class:          sfPropelDatabase
       param:
         dsn:          mysql://USERNAME:PASSWORD@DB_HOST_1/DB_NAME

     dataBases2:
       class:          sfPropelDatabase
       param:
         dsn:          mysql://USERNAME:PASSWORD@DB_HOST_2/DB_NAME

Dada esta estructura de mi databases.yml, me obliga a modificar el archivo PROJECT_DIR/config/propel.ini para al momento de realizar symfony propel-build-schema xml con el fin de que se generen los schema.xml que necesito para los distintos modelos del proyecto. Recomiendo cambiar el nombre del esquema por cada conexión que exista, Ejemplo: dataBases2.schema.xml

Lo principal a tener en cuenta es que siempre debe existir una conexión denominada “propel”. Esto es necesario para ciertas cosas, para que funcione correctamente el comando “symfony propel-build-model”, etc especialmente desde los usos schema.yml que el nombre de conexión.

Ahora, cuando vayas a realizar una consulta, sólo tienes que decirle a Propel qué conexión va a utilizar. De forma predeterminada, Propel utiliza la conexión “propel”; Aquí es donde se usa de las dos conexiones definidas en el archivo PROJECT_DIR/config/databases.yml descrito anteriormente:

$c = new Criteria();
$articles = ArticlePeer::doSelect($c, Propel::getConnection('dataBases2'));

Organizar el modelo en una estructura de subpaquetes

La manera de organizar nuestro modelo, es con los schema.xml que generemos; es muy sencillo.

Debemos modificar el atributo package de nuestro schema.xml; este indica la ruta donde se guardan las clases generadas automáticamente. Su valor por defecto es lib/model/, pero se puede modificar
para organizar el modelo en una estructura de subpaquetes. Si por ejemplo no se quieren
mezclar en el mismo directorio las clases del núcleo de la aplicación con las clases
de un sistema de estadísticas, se pueden definir dos esquemas diferentes con los paquetes