Relaciones uno a uno

Un caso típico para este tipo de relación es el de un usuario y su perfil. Un usuario solamente tiene un perfil y un perfil solo puede pertenecer a un usuario.

User:
  tableName: user
  columns:
    id:
      type: integer(4)
      primary: true
      notnull: true
      autoincrement: true
    email:
      type: string(255)
      notnull: true
      unique: true
    password:
      type: string(45)
 
Profile:
  tableName: profile
  columns:
    user_id:
      type: integer(4)
      primary: true
      notnull: true
      autoincrement: false
    nickname: string(255)
  relations:
    User:
      class: User
      local: user_id
      foreign: id
      foreignAlias: Profile
      type: one
      foreignType: one

Con esta relación, podremos acceder al perfil de un usuario así:

$user->Profile->nickname // obtenemos el nickname del perfil del usuario

Relaciones uno a muchos:

Un ejemplo de este tipo de relación es el de los usuarios y sus números de teléfono. Un usuario puede tener varios números de teléfono pero un teléfono solo puede pertenecer a un usuario.

User:
  tableName: user
  columns:
    id:
      type: integer(4)
      primary: true
      notnull: true
      autoincrement: true
    email:
      type: string(255)
      notnull: true
      unique: true
    password:
      type: string(45)
 
Telephone:
  tableName: telephone
  columns:
    id:
      type: integer(4)
      primary: true
      notnull: true
      autoincrement: true
    user_id:
      type: integer(4)
      notnull: true
    number:
      type: string(255)
  relations:
    User:
      class: User
      local: user_id
      foreign: id
      foreignAlias: Telephones
      type: one
      foreignType: many

Para acceder a los números de teléfono de un usuario, podemos hacer:

foreach($user->Telephones as $telephone){
  echo $telephone->number;
}

Relaciones muchos a muchos

Para terminar, un caso típico de esta relación es la que podemos encontrar entre los artículos de un blog y sus etiquetas. Un artículo puede tener varias etiquetas y una etiqueta puede asignarse a varios artículos. En esta relación necesitaremos obligatoriamente una tercera tabla (article_tags) para poder relacionar la tabla articles y la tabla tags.

Article:
  tableName: articles
  columns:
    id:
      type: integer(4)
      primary: true
      notnull: true
      autoincrement: true
    title:
      type: string(100)
      notnull: true
 
Tag:
  tableName: tags
  columns:
    id:
      type: integer(4)
      primary: true
      notnull: true
      autoincrement: true
    name:
      type: string(100)
      notnull: true
  relations:
    Article:
      foreignAlias: Tags
      class: Article
      refClass: ArticleTag
 
ArticleTag:
  tableName: article_tags
  columns:
    article_id:
      type: integer(4)
      primary: true
    tag_id:
      type: integer(4)
      primary: true
  relations:
    Article:
      foreignAlias: ArticleTags
    Tag:
      foreignAlias: ArticleTags

Podremos obtener el nombre de todos los tags de un artículo de la siguiente manera:

foreach($article->ArticleTags as $article_tag){
      echo $article_tag->Tag->name;
}

¡Cualquier duda, en los comentarios!

“The default context does not exist”

El problema es que estás utilizando un método de un objeto que utiliza sfContext (para recuperar valores del archivo app.yml, por ejemplo). Parece ser que Symfony no crea una instancia de sfContext y nos devuelve este error.

La siguiente línea debería resolver el problema. La colocaremos en primer lugar dentro de la función execute:

sfContext::createInstance($this->configuration);

Por ejemplo:

1
2
3
4
5

protected function execute ($arguments = array(), $options = array())
{
  sfContext::createInstance($this->configuration);
  // Aqui nuestro codigo
}

Primero creamos el formulario de login, por lo que creamos un nuevo archivo:

/lib/form/LoginForm.class.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<?php
class LoginForm extends BaseForm
{
  public function configure()
  {
    parent::configure();
 
    $this->setWidgets(array(
      'email'        => new sfWidgetFormInput(),
      'password'  => new sfWidgetFormInputPassword(),
    ));    
 
    $this->setValidators(array(
      'email'        => new sfValidatorEmail(array('required'=>true), array('required'=>'El email es obligatorio')),
      'password'  => new sfValidatorString(array('required'=>true), array('required'=>'Escribe tu contraseña')),
    ));
 
    $this->widgetSchema->setNameFormat('login[%s]');
    $this->widgetSchema->setFormFormatterName('list');
 
  }
 
}

El formulario no tiene mayor misterior. Un input text para el email y un input password para la contraseña. Validamos que se hayan rellenado los dos campos.

Editamos las actions del módulo user que creamos en el post anterior para añadir el login.

/apps/frontend/modules/user/actions/actions.class.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

<?php
class userActions extends sfActions
{
  public function executeLogin(sfWebRequest $request)
  {
    $this->form = new LoginForm();
 
    if($request->isMethod("post")){
        $this->form->bind($request->getParameter("login"));
 
        if($this->form->isValid()){
           if(!$user = UserTable::login($this->form->getValue("email"), $this->form->getValue("password"))){
               // No hemos conseguido loguear al usuario
               // Redirigimos de nuevo al login con un mensaje de error
               $this->getUser()->setFlash("error", "datos incorrectos");
               $this->redirect("@user_login");
           }else{
               // Logueamos
               $this->getUser()->setAuthenticated(true);
               $this->getUser()->setAttribute("id",$user->id);
 
               // Comprobamos si tiene referer, si no, le llevamos a la homepage
               $url = $this->getUser()->getAttribute("referer",false)?:"@homepage";
               $this->getUser()->setAttribute("referer", false);
               $this->redirect($url);
           }
        }
 
  }
 
}

Tenemos que comprobar si existe ese email junto con esa contraseña en nuestra base de datos. Si es así, logueamos al usuario y, si no, mostramos un mensaje de error.
La comprobación de si existe el usuario en la base de datos la hacemos en la linea 12, donde llamamos al método estático “login” del archivo UserTable.class.php del modelo.

/lib/model/doctrine/UserTable.class.php

1
2
3
4
5
6
7
8
9
10
11

<?php
class UserTable extends Doctrine_Table
{
    public static function login($email,$password){
      return Doctrine_Query::create()
        ->from('User u')
	->where('u.email = ?', array($email))
        ->andWhere('u.password = ?', array(md5($password))) // Podrimos usar otro algoritmo, en este caso utilizamos md5
	->fetchOne();
    }
}

Y eso es todo, lo más sencillo para el final: la plantilla donde mostramos el formulario.

/apps/frontend/modules/user/templates/loginSuccess.php

1
2
3
4
5
6
7

<?php if($sf_user->getFlash("error")): ?>
    <div class="error"><?php echo $sf_user->getFlash("error"); ?></div>
<?php endif; ?>
<form action="<?php echo url_for("@user_login"); ?>" method="post">
  <?php echo $form; ?>
  <input type="submit" value="Entrar" />
</form>

En este paso sería lógico desarrollar el logout para poder cerrar la sesión en la web. Para ello modificamos de nuevo la actions de nuestro módulo para añadir la nueva funcionalidad:

/apps/frontend/modules/user/actions/actions.class.php

1
2
3
4
5
6
7
8
9

<?php
class userActions extends sfActions
{
  public function executeLogout(sfWebRequest $request){
    $this->getUser()->setAuthenticated(false);
    $this->getUser()->getAttributeHolder()->clear();
    $this->redirect("@homepage");
  }
}

Para ejecutar el logout, solo debemos crear un enlace en nuestra web donde se llame a esta action. No necesitamos plantilla ya que después de logout siempre redirigiremos a la homepage.

<?php echo link_to("Cerrar sesión", '@user_logout'); ?>

Debemos añadir las siguientes rutas en el archivo routing.yml:

user_login:
  url:   /login
  param: { module: user, action: login }
 
user_logout:
  url:   /logout
  param: { module: user, action: logout }

Cualquier duda en los comentarios!

Para este post, la intención es crear un formulario de registro de usuarios sencillo desde cero para Symfony 1.4, sin la complejidad de un plugin ya que muchas veces tienen funcionalidades que no necesitaremos en nuestro proyecto.

Antes de empezar, evidentemente, crearemos un proyecto nuevo y generamos un modulo llamado “user”.

Primero modificamos el archivo schema.yml, añadiendo una tabla user básica y sencilla.

/config/doctrine/schema.yml

1
2
3
4
5
6
7
8
9

User:
  tableName: user
  actAs:
    Timestampable: ~
  columns:
    email:
      type: string(255)
    password:
      type: string(45)

Indicamos que se comporte como Timestampable para que se creen automáticamente los campos created_at y updated_at. No nos olvidemos generar las consultas sql y ejecutarlas en nuestra base de datos.

En el segundo paso, vamos a crear el formulario para el registro del usuario. Creamos un archivo nuevo en /lib/form/ llamado RegisterForm.class.php

/lib/form/RegisterForm.class.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

<?php
class RegisterForm extends BaseForm
{
    public function configure()
    {
        parent::configure();
 
        $this->setWidgets(array(
	    'email'     => new sfWidgetFormInput(),
	    'password'  => new sfWidgetFormInputPassword(),
            'password2' => new sfWidgetFormInputPassword(),
	));
 
	$this->setValidators(array(
            'email'        => new sfValidatorEmail(array('required'=>true), array('required'=> "El email es obligatorio")),
            'password'  => new sfValidatorString(array('required'=>true), array('required'=> "La contraseña es obligatoria")),
            'password2' => new sfValidatorString(array('required'=>true), array('required'=> "La contraseña es obligatoria")),
	));
 
	$this->widgetSchema->setNameFormat('register[%s]');
        $this->widgetSchema->setFormFormatterName('list');
 
        $this->validatorSchema->setPostValidator(new sfValidatorAnd(array(
            new sfValidatorSchemaCompare('password2', sfValidatorSchemaCompare::EQUAL, 'password', array('throw_global_error' => true), array('invalid' => "Las dos contraseñas no coinciden")),
            new sfValidatorDoctrineUnique(array('model' => 'User', 'column' => array('email')), array('invalid'=> "Este email ya está en uso"))
        )));
    }
}

Los formularios pueden darnos muchos quebraderos de cabeza al principio ya que es algo dificil de entender a la primera, por lo que voy a explicarlo un poco más en detalle.

1
2
3
4
5

$this->setWidgets(array(
    'email'     => new sfWidgetFormInput(),
    'password'  => new sfWidgetFormInputPassword(),
    'password2' => new sfWidgetFormInputPassword(),
));

Indicamos que para el campo email queremos un input normal. Como se puede apreciar, le decimos que para los campos contraseña queremos un campo input password.

1
2
3
4
5

$this->setValidators(array(
    'email'        => new sfValidatorEmail(array('required'=>true), array('required'=> "El email es obligatorio")),
    'password'  => new sfValidatorString(array('required'=>true), array('required'=> "La contraseña es obligatoria")),
    'password2' => new sfValidatorString(array('required'=>true), array('required'=> "La contraseña es obligatoria")),
));

Ahora los validadores. El campo email, evidentemente, debe ser un email. El validador sfValidatorEmail se encarga de comprobar que sea un formato de email válido.
Los campos password son obligatorios y no pueden estar vacíos. Podríamos decirle que tienen que tener una longitud mínima y máxima con las opciones max_length y min_length.

1
2
3
4

$this->validatorSchema->setPostValidator(new sfValidatorAnd(array(
    new sfValidatorSchemaCompare('password2', sfValidatorSchemaCompare::EQUAL, 'password', array('throw_global_error' => true), array('invalid' => "Las dos contraseñas no coinciden")),
    new sfValidatorDoctrineUnique(array('model' => 'User', 'column' => array('email')), array('invalid'=> "Este email ya está en uso"))
)));

Vamos a añadir unos validadores un poco más complejos. En el primero, comprobamos que los dos campos de contraseña deben ser iguales. Para ello utilizamos el validador sfValidatorSchemaCompare. Es típico hacer esta comprobación en todos los formularios de registro de usuarios.
En el segundo caso, comprobamos que el email introducido por el usuario no esté ya introducido en la base de datos y, por tanto, en uso por otro usuario. Utilizamos el validador sfValidatorDoctrineUnique.

Ya tenemos el formulario preparado para su uso. Editamos el archivo actions.class.php de nuestro módulo “user” y añadimos la acción “Register”:

/apps/frontend/modules/user/actions/actions.class.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<?php
class userActions extends sfActions
{
  public function executeRegister(sfWebRequest $request)
  {
 
    $this->redirectIf($this->getUser()->isAuthenticated(), "@homepage");
 
    $this->form = new RegisterForm();
 
    if($request->isMethod("post")){
 
       $this->form->bind($request->getParameter("register"));
       if($this->form->isValid()){
 
           $user = new User();
           $user->email = $this->form->getValue("email");
           $user->password = md5($this->form->getValue("password")); // podriamos utilizar otro sistema para encriptar la contraseña
           $user->save();
 
           $url = $this->getUser()->getAttribute("referer",false)?:"@homepage";
           $this->getUser()->setAttribute("referer",false);
           $this->redirect($url);
       }
    }
  }
}

En la línea 7 le indicamos que si el usuario ya está logueado le redirija a la homepage.

Hemos utilizado el algoritmo md5 para encriptar la contraseña antes de guardarla en la base de datos. Podríamos utilizar otro algoritmo como sha1 o uno propio. Es totalmente recomendable encriptar las contraseñas y no guardarlas en texto plano en nuestra base de datos por motivos de seguridad.

Por último, creamos la plantilla donde se mostrará el formulario de registro.

/apps/frontend/modules/user/templates/registerSuccess.php

1
2
3
4

<form action="<?php echo url_for("@user_register"); ?>" method="post">
  <?php echo $form; ?>
  <input type="submit" value="Registrarse" />
</form>

Debemos añadir la siguiente ruta en el archivo routing.yml:

user_register:
  url:   /register
  param: { module: user, action: register }

Y eso es todo, ya hemos creado un sistema muy básico de registro de usuarios en Symfony 1.4. A partir de aquí se puede expandir e incluir las funcionalidades que queramos.
En un próximo post, realizaremos el login y el logout.

Cualquier duda o si hay que explicar algo mejor, en los comentarios

En casos como estos es necesario tomar estas dos consultas como un todo y si falla una de las dos operaciones, volver atrás y deshacer la operación. Para ello se utilizan las transacciones.

En este ejemplo vamos a ver como realizar transacciones con el ORM Doctrine y Symfony (no necesariamente debemos utilizar Symfony).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

$conn = Doctrine_Manager::getInstance()->getCurrentConnection();
$conn->beginTransaction();
 
try{
 
    /** Hacemos las operaciones necesarias
      * para realizar la transferencia bancaria */
 
    $userA = UserTable::getById($userA_id);
    $userB = UserTable::getById($userB_id);
 
    $userA->money -= 20;
    $userA->save();
 
    $userB->money += 20;
    $userB->save();
 
    $conn->commit();
}
catch (Exception $e){
    $conn->rollBack();
    throw $e;
}

Si las dos operaciones se realizan con éxito, quedará reflejado en la base de datos. Si por el contrario cualquiera de las dos consultas fallará, se desharán los cambios (rollBack) y no se guardarán en la base de datos (mostramos el error y deberemos tratarlo según nuestros intereses).

Voy a explicar como instalar NetBeans en Ubuntu y empezar un proyecto utilizando svn+ssh.

1) Descargar e instalar NetBeans.
Lo haremos desde su página web oficial: http://netbeans.org/ La última versión a la hora de escribir este post, es la 6.9.1.
Descargaremos la versión PHP. Podemos elegir el idioma del IDE, aunque recomiendo descargarlo en inglés. No es lo mismo hacer un “checkout” o “commit”, que un “comprobar” o “subir cambios”. Personalmente, me lío

Una vez descargado el instalador, tenemos que darle permisos de ejecución. Pinchamos con el botón derecho / propiedades / permisos / permitir ejecutar el archivo como un programa. Cerramos y hacemos doble click en el archivo y seleccionamos Ejecutar. La instalación empezará en este momento.

2) Soporte svn+ssh
NetBeans ya tiene instalado el plugin de svn. Lo que vamos a hacer es importar un proyecto que tengamos en nuestro servidor de svn, conectándonos mediante svn+ssh. Para ello necesitamos primero crear un par de claves RSA para que podamos conectarnos mediante ssh al servidor svn sin necesidad de tener que introducir la contraseña cada vez.

En local, utilizamos el comando ssh-keygen:

ssh-keygen -t rsa

Nos da la opción de introducir una frase para cifrar la clave privada. Cifrar la clave privada nos dará más seguridad en caso de intento de robo de esta clave, pero en este caso no lo vamos a hacer ya que el objetivo es no tener que escribir la contraseña cada vez que nos queramos conectar al servidor (si ciframos la clave privada, habrá que introducir la frase para descifrarla).

Este comano nos crea dos archivos: id_rsa (clave privada) e id_rsa.pub (clave pública). Tenemos que copiar la clave pública al servidor svn.

Podemos copiar el archivo id_rsa.pub mediante ftp o utilizando el comando scp:

scp id_rsa.pub usuario@dominio:/home/usuario

Cuando tengamos la clave pública en el servidor, tenemos que añadirla al fichero authorized_keys que esta en el directorio .ssh de nuestra home. Si no existe el directorio, lo creamos:

mkdir $HOME/.ssh

Dentro de este directorio, tenemos que incluir la clave pública en el fichero authorized_keys:

cat id_rsa.pub >> authorized_keys

Después de esto, ya no necesitaremos introducir nuestra contraseña cada vez que queramos conectarnos al servidor (desde nuestro ordenador local, claro).

3) Importar proyecto svn
Ya estamos preparados para importar un proyecto svn a NetBeans utilizando svn+ssh.
En Netbeans, vamos al menú Team>Subversion>Checkout. Se nos abrirá una ventana en la que tenemos que introducir la URL del repositorio (Repository URL) y el túnel SSH (Tunnel Command).
En el primer campo escribimos la ruta a nuestro repositorio, por ejemplo:

svn+ssh://midominio.com/miproyecto

Y en Tunnel Command, introducimos:

ssh -q -l USUARIO -i /home/USUARIO/.ssh/id_rsa

Vemos como en el comando anterior hacemos uso del archivo de clave privada id_rsa, así no tendremos que escribir la contraseña cada vez.

La siguiente ventana esta dividida en dos partes. En la de arriba seleccionaremos la parte del repositorio que queremos importar (checkout). Por defecto nos descargaremos todo (podemos seleccionar la rama Trunk si la hubiera). En parte de abajo de la ventana, seleccionamos donde queremos descargar el proyecto en local.

En el siguiente paso nos preguntará si queremos crear un proyecto en local. Le decimos que sí. Creamos un PHP Application (la primera opción). Lo ideal es que el directorio del proyecto que estamos creando sea el mismo que el de sincronización con svn. Así, trabajamos y hacemos cambios en los archivos descargados de svn directamente, por lo que es más fácil después subir los cambios al servidor. Recomiendo separar los metadata del proyecto Netbeans a otra carpeta, para que no se añadan al proyecto y se suban la próxima vez al servidor svn (aunque se podría hacer un ignore).

Como vemos en la captura, el proyecto desde svn lo descargo en trunk, mientras que los metadata del proyecto (archivos de configuración de NetBeans) lo dejo en la carpeta MiProyecto:

Y ya lo tendremos! Podemos activar la barra de svn para hacernos el trabajo más sencillo (Window / Versioning / Subversion) a la hora de subir los cambios al servidor.

4) Theme con colores oscuros
Si pasamos la mayor parte del día programando, es mejor para la vista tener colores oscuros de fondo. El color blanco (por defecto en la mayoría de IDEs) cansa mucho la vista y a la larga puede ser perjudicial para los ojos. Así que vamos a instalar un theme con colores oscuros.

El mejor que he encontrado es este: http://net.tutsplus.com/freebies/themes/netbeans-twilight-theme/ y lo podemos descargar desde aquí o aquí (mirror en mi servidor).

Para importarlo en NetBeans, vamos a Tools / Options y pulsamos en el botón Import. Buscamos el archivo .zip (importante, no hay que descomprimirlo!), seleccionamos que queremos importar todas las opciones y pulsamos en aceptar. Después de reiniciar NetBeans, vamos a Tools / Options y en la pestaña Fonts and Colors seleccionamos el Profile Netbeans_Twilight. Ya tendremos nuestro entorno con colores oscuros.

Para mi gusto, el tamaño de letra de este theme es demasiado pequeño. Yo, en Fonts and Colors (una vez activado el theme) selecciono el tipo de fuente “Monospaced”, estilo “Plain” y tamaño “13″.

Con estos pasos tenemos nuestro entorno de desarrollo listo para empezar.

Symfony tiene un sistema de logs bastante decente, que nos informa de todo lo que ocurre cada vez que cargamos una nueva página. Vamos a hacer algo sencillo: vamos a escribir nuestros propios mensajes de log personalizados y los escribiremos manualmente en el momento que consideremos oportuno y deseamos tener un control. Además, escribiremos estos logs en un archivo aparte del que utiliza Symfony por defecto. Así podremos leer directamente ese archivo sin tener otros logs mezclados con los que realmente nos interesa.

Primero, vamos a crear un nuevo archivo llamado CustomLog.class.php en la carpeta /lib/:

1
2
3
4
5
6
7
8
9
10
11

<?php
 
class CustomLog{
  static public function newLog($message) {
 
        $logFile = sfConfig::get('sf_log_dir').'/custom_logs.log';
        $custom_log = new sfFileLogger(new sfEventDispatcher(), array('file' => $logFile));
        $custom_log->info($message);
 
  }  
}

El archivo donde guardaremos nuestros logs personalizados, lo encontraremos en “/log/custom_logs.log”.

Para escribir un nuevo log desde cualquier parte del código, simplemente deberemos hacer:

1

CustomLog::newLog("Escribimos un nuevo log");

Si abrimos nuestro archivo de logs personalizados, encontraremos algo como esto:

1

Jul 05 22:31:41 symfony [info] Escribimos un nuevo log

Así podremos llevar un control de lo que ocurre en nuestra web.

Quizás haya una forma mejor de hacerlo. Si es así, no dudes en dejar tu propuesta en los comentarios. A lo mejor también sería conveniente escribir esas 3 lineas dentro de un try.. catch, por lo que pudiera pasar.

En la nueva empresa donde trabajo (BlackSlot) he empezado a utilizar Doctrine y, ante mi sorpresa, me ha encantado. Me he dado cuenta de que si sabes sql es muy fácil aprender Doctrine y con resultados muy buenos. Con Propel, aunque sepas sql, tienes que aprender a usarlo y pensar las conversiones desde sql a Propel. Es un lenguaje nuevo.

Ante este escenario y como tengo un proyecto recién empezado, me decidí a migrarlo de Propel a Doctrine.

Tengo que destacar que la migración es realmente costosa. Si no fuese por que acabo de empezar el proyecto y no está muy avanzado, hubiese tenido que seguir con Propel. Personalmente, lo que más cuesta es transformar todo el modelo a Doctrine (todo depende de cuanto lleves hecho). Si es un proyecto acabado y bastante elaborado, te puede llevar días. Al modelo hay que añadir el modificar el schema.yml con el formato apropiado para Doctrine.

Otro quebradero de cabeza son los plugins en Propel que has utilizado en tu proyecto. El más típico es el sfGuardPlugin para llevar las cuentas de usuario. Tendrás que instalar el plugin sfDoctrineGuardPlugin que es el equivalente para Doctrine.

Si aún después de haber leído esto, sigues queriendo migrar de Propel a Doctrine un proyecto empezado, estos son los pasos que tienes que seguir:

¡No te olvides de hacer un backup de todo primero!

1) Editamos el fichero config/ProjectConfiguration.class.php y añadimos esta línea con la que cargamos todos los plugins excepto el de Propel.

1

$this->enableAllPluginsExcept(array('sfPropelPlugin'));

2) Borrar directorio plugins/sfGuardPlugin si es que lo tenemos instalado.

3) Borramos el actual schema de base de datos config/databases.yml
y reconfiguramos el proyecto para utilizarlo con Doctrine

1

php symfony configure:database --name=doctrine --class=sfDoctrineDatabase "mysql:host=localhost;dbname=nombre_base_de_datos" usuario contraseña

4) Ejecutamos:

1

php symfony plugin:publish-assets

para crear un enlace a sfDoctrinePlugin en el directorio web.

5) Borramos unos ficheros propios de Propel

1
2

rm web/sfPropelPlugin
rm config/propel.ini

6) Como es un proyecto empezado, supongo que tienes una base de datos ya creada.

Creamos el directorio donde alojamos el schema.yml para Doctrine:

1

mkdir config/doctrine

Y con el siguiente comando, recreamos el schema a partir de la base de datos existente:

1

php symfony doctrine:build-schema

No te olvides revisarlo, sobre todo las relaciones entre tablas.

7) Borramos el modelo anterior

1

rm -rf lib/model/*

Y lo volvemos a generar a partir del nuevo archivo schema.yml

1
2
3

symfony doctrine:build-model
symfony doctrine:build-forms
symfony doctrine:build-filters

A partir de aquí viene el trabajo duro: reescribir el modelo que teníamos en Propel y adaptarlo a Doctrine en las clases adecuadas del modelo.

También deberás instalar el plugin sfDoctrineGuardPlugin si lo estimas necesario (http://www.symfony-project.org/plugins/sfDoctrineGuardPlugin)

Espero que le pueda servir a alguien.