Si alguna vez os habéis parado a ver el código generado por el modelo, podréis observar que la clase Base es más o menos así:

<?php 
abstract class BaseItem extends sfDoctrineRecord
{
    public function setTableDefinition()
    {
       // Aquí el código de definición de la tabla
    }
 
    public function setUp()
    {
       // Aquí las relaciones y los behaviours
    }
}
?>

Algo que siempre me había llamado la atención de este código es, ¿por qué la clase base extiende de sfDoctrineRecord en lugar de hacerlo directamente de Doctrine_Record?

Esta pregunta no tiene una única respuesta, ya que son varias funcionalidades las que añade este wrapper:

• Funcionalidades específicas para objetos I18n. Añade un proxy al objeto Translate de manera que si al acceder a un atributo del objeto no se encuentra, intentará buscarlo entre los de su objeto Translate asociado (para la cultura definida en ese momento) antes de lanzar una exception (algo parecido a esto)
• Getter y Setter para las relaciones de objeto, de manera que podamos tratar “igual” tanto a las relaciones como los atributos de las tablas, una funcionalidad al más estilo Propel,
• Hidratación específica para atributos Date y Timestamp. sfDoctrineRecord añade un método, sfDoctrineRecord::getDateTimeObject, que permite obtener los campos de fecha y timestamp no como una cadena de texto, sino como un objeto DateTime. De manera análoga, sfDoctrineRecord::setDateTimeObject() permite fijar el valor de un campo date o timestamp a partir de un campo DateTime en lugar de una cadena de texto correctamente formateada, algo muy útil en aplicaciones internacionalizadas donde las fechas se pueden insertar de diferentes maneras y requieren un trato previo en función de la cultura del usuario.