First of all, my stored functions are in separate .sql files in my plugin’s data/sql/ directory in the interests of following convention within the project’s directory structure.

Secondly, in myPlugin/config/MyPluginConfiguration.class.php file, I have the following for the initialize() method.:

public function initialize()
{
  sfConfig::set("zz_myplugin_dir", $this->getRootDir());
  $this->dispatcher->connect("command.post_command", array($this, 'initializeStoredFuncs'));
}

We listen for the command.post_command event which we can then check to see if it’s a Doctrine insert-sql task being run. We also check to see if the function already exists before attempting to create it – if not, then carry on.

public static function initializeStoredFuncs(sfEvent $event)
{
  static $doneConfig = false;
 
  if ($doneConfig)
  {
    // Already done it.
    return;
  }
 
  if (!($event->getSubject() instanceof sfDoctrineInsertSqlTask))
  {
    // Not inserting any SQL. No point continuing
    return;
  }
 
  // Get database connection
  $con = Doctrine_Manager::connection();
 
  // Configure function 1
  self::addStoredRoutine($con, "myFuncName1", "myFuncName1.sql");
 
  // Configure function 2
  self::addStoredRoutine($con, "someOtherFunc", "someOtherFunc.sql");
 
  // Set config completed flag for later
  $doneConfig = true;
}
 
/**
* Adds a stored procedure into the database
*
* @param string $con Connection to use
* @param string $routineName Routine name
* @param string $routineFile Filename inside our [plugin dir]/data/sql/
*/
protected static function addStoredRoutine($con, $routineName, $routineFile)
{
  $options = $con->getOptions();
  $dsn = $options["dsn"];
  preg_match("/dbname=([^;]+)[;]?/", $dsn, $matches);
  $dbname = $matches[1];
 
  $sql = "SELECT COUNT(*) AS c FROM information_schema.routines WHERE routine_name = '{$routineName}' AND routine_schema = '{$dbname}'";
  try
  {
    $dbh = $con->getDbh();
  }
  catch (Exception $e)
  {
    // No database available - can't carry on
    return;
  }
 
  $resultSet = $dbh->query($sql);
  $results = $resultSet->fetch();
  if ($results["c"] == 0)
  {
    // Create the function
    $sqlRoutine = file_get_contents(sfConfig::get("zz_myplugin_dir") . "/data/sql/" . $routineFile);
    $con->getDbh()->prepare($sqlRoutine)->execute();
  }
}

I’m not a massive fan of the way the database name has been retrieved but it works for now :-) I’m pretty sure there’s a neater way of accomplishing the above too, but this is working consistently and allows the stored functions to become part of a plugin, so that if the plugin is removed at a later date, then any subsequent database builds will not have unnecessary routines hanging around.

The problem I discovered was that obviously Doctrine didn’t know what the conditional relationships were, since it was dependant on the type column. I researched some different approaches:

1. Doctrine’s RawSql

   This approach worked for generating the correct SQL query without a problem, but the issue then arose of how Doctrine could hydrate the result set. Answer was – it couldn’t :-) Well, I lie – I could use Doctrine::HYDRATE_SCALAR but I had issues with other related models, where I was joining to a table twice but under different aliases, which failed, since the scalar hydration would override earlier joins on the same table.

2. Column aggregation

   Column aggregation looked great initially – I could have a “TypeAEntry” and a “TypeBEntry”, and Doctrine would have handled the typing of the Entry automatically. I couldn’t however see a way to query “in reverse” – get all Entries and their associated models.

3. Write a raw SQL query, and use Doctrine’s PDO instance to retrieve the data.

Option 3) was the one I settled for in the end. It meant of course that I had to specify column names, and perform all the joins myself, but it did mean I could specify precisely what data I wanted back. This came back in the form of a normal array.  I’d tried to stay away from this option intially, but after spending too long researching the other 2 and hitting brick walls, I bit the bullet and dropped down to the raw stuff.  And hey presto!

Note – this approach will only work if you want the data to be read-only. If you want to then use Doctrine’s model goodness, you’ll need to work out how to transform that *back* into a model.