This has given me a good opportunity to evaluate both techniques and determine my personal preference for working.

The more traditional technique is to pass values to methods using individual parameters as in the example below:-

public function someMethod($name, $age = null)
{
  // do something
}

The benefit I have found with this method is that you can clearly identify what needs to be passed to the method, however, if you need to change the method to include an additional parameter it means that you have to update every call to this method so that every parameter is specified.

An alternative (and my personal preference) is to used an option array like in the following example

public function someMethod($options = array())
{
  $name = $options['name'];
  // do something
}

In this case, if you need to add an extra parameter to the method you can simply add the value to the options array and update the functionality within the method.  You do not necessarily need to update the calls to this method that are already in place  because they should still work fine provided the updated functionality is defined in such a way that it allows for the new parameter to be optional.

In addition, I feel that if you provide decent documentation regarding the options array (which should include a list of all the options values allowed), especially if it can be picked up via auto-completion in IDEs such as Netbeans, then this is just as easy to use as methods which are defined to accept individual parameters.

References

http://weblogtoolscollection.com/archives/2010/02/25/passing-parameters-as-variables-vs-passing-parameters-as-an-array/

function get_raw_sql($query) {
    if(!($query instanceof Doctrine_Query)) {
        throw new sfException('Not an instanse of a Doctrine Query');
    }
 
    $query->limit(0);
 
    if(is_callable(array($query, 'buildSqlQuery'))) {
        $queryString = $query->buildSqlQuery();
        $query_params = $query->getParams();
        $params = $query_params['where'];
    } else {
        $queryString = $query->getSql();
        $params = $query->getParams();
    }
 
    $queryStringParts = split('\?', $queryString);
    $iQC = 0;
 
    $queryString = "";
 
    foreach($params as $param) {
        if(is_numeric($param)) {
            $queryString .= $queryStringParts[$iQC] . $param;
        } elseif(is_bool($param)) {
            $queryString .= $queryStringParts[$iQC] . $param*1;
        } else {
            $queryString .= $queryStringParts[$iQC] . '\'' . $param . '\'';
        }
 
        $iQC++;
   }
   for($iQC;$iQC < count($queryStringParts);$iQC++) {
       $queryString .= $queryStringParts[$iQC];
   }
 
    echo $queryString;
}

I hope that it proves useful.

While I am writing these actions I often find that I have to delete the contents of the MySQL tables as you can never write the routine complete and accurate in one go so as you build it up in smaller steps you find that you have to get rid of the previously old data.

This presented me with 2 problems:-

• Using DELETE FROM [TABLENAME] does not reset the auto-incrementing fields so if you have anything that is based on the id during the rest of the import then you’re going to have issues.
• There is a lot of clicking in phpMyAdmin to empty the tables, especially if you forget about the foreign key relationships.

I found that MySQL had a TRUNCATE TABLE but this is not directly available via Doctrine as the TRUNCATE TABLE is function of the type of database you are using and Doctrine cannot assume you are always using MySQL so therefore it cannot provide a generic method to call it.

Having said that it was not too difficult to run the TRUNCATE TABLE from within my Symfony project.  All I had to do was add the following lines of code to an action within the actions.class.php for my import module and now it empties each table I have defined before importing the data and it also resets the auto-incrememt ids all my tables start from id = 1 each time I run the import.

$doctrine = Doctrine_Manager::getInstance()->getCurrentConnection()->getDbh();
$doctrine->query('TRUNCATE TABLE order_items');
$doctrine->query('TRUNCATE TABLE orders');
unset($doctrine);

Be careful which order you run the TRUNCATE TABLE calls so you avoid the foreign key relationship issues.

Let me know if this helps you out.  Enjoy!

As my use of Symfony is increasing I find myself frustrated that there doesn’t appear to be an easy way to get the raw SQL from a doctrine query object so I can simply output it and paste it into phpMyAdmin to debug problems with the SQL. I may be wrong about this but as yet I have not found a built in function to perform this operation.

Sure I am able to output the query with the “?” indicating where the necessary values are to go and I can also easily output the array of query parameters so I can substitute these manually but this takes time and it would be much much simpler and quicker to just output the whole query with the substitution already done so it’s a simply copy and paste of the raw SQL from the doctrine query object straight into phpMyAdmin.

I have wrote a quick function to do this and I had meant to post this for a while but I just have not had the chance to get round to it until now.

The code for this is can be found below:-

function get_raw_sql($query) {
    $query->limit(0);
 
    $queryStringParts = split('\?', $query->getSQL());
    $iQC = 0;
    $queryString = "";
 
    foreach($query->getParams() as $param) {
        if(is_numeric($param)) {
            $queryString .= $queryStringParts[$iQC] . $param;
        } elseif(is_bool($param)) {
            $queryString .= $queryStringParts[$iQC] . $param*1;
        } else {
            $queryString .= $queryStringParts[$iQC] . '\'' . $param . '\'';
        }
        $iQC++;
   }
 
   for($iQC;$iQC < count($queryStringParts);$iQC++) {
       $queryString .= $queryStringParts[$iQC];
   }
   echo $queryString;
}

In my case this is a global function but it could very well be written as a static function in a debug class.

$query is a Doctrine Query object and this function iterates round the parameters for the query string and replaces each instance of a “?” with the corresponding variable. It has a crude (but fairly effective so far) method of determine whether it’s a string, number or boolean when performing this substitution and so far this works well in all the cases I’ve used it.

The $query->limit(0); is very important as the $query->getSQL() function does not work properly in this context if a limit is specified on the query so as we are wanting to debug the SQL and a majority of the time we are not concerned with the limit I have opted to remove this from this routine.

Hopefully this will allow you to save some time and effort trying to get the raw SQL from your doctrine query objects and I would appreciated any comments, thoughts or ideas you may have for improvement.

If you post a question and no-one managed to provide you with an answer do you:-

• post up your solution when you’ve found it? or
• simply forget about the post and leave everyone else to figure it out themselves too?

Unfortunately there are a number of people in the latter category (myself included from time to time) and being a web developer means I run into this type of issue more than I would like but, I’ve recently come across yet another great reason why you should go back and answer your own question when you have managed to work out the answer.

A few months ago I was working for Alienation Digital in Glasgow and I had a problem with creating a custom validator using a callback in Symfony and I posted the problem to the Symfony forums, and later, the solution I used to rectify the problem.

Fast forward a few months and you now find me working for Line Digital in Edinburgh and I’m now working on a new project which has a very similar problem. Obviously I don’t have access to the code I wrote while at Alienation Digital but unsurprisingly I had forgotten I have already solved this problem as it’s months since I had to last think about it.

So out comes Google again, I enter my search phrase and I am amazed that the first forum post (which resulted in the path to the solution) was my own post that I wrote while at Alienation Digital.

So the moral of the story is to answer your own posts, even if you do end up feeling like you’re talking to yourself because you the next person your post helps out may be yourself.

Fatal error: Uncaught exception ’sfConfigurationException’ with message ‘Configuration file "/usr/lib/php/symfony/config/config/core_compile.yml" does not have a registered handler.’ in /usr/lib/php/symfony/config/sfConfigCache.class.php:101

Looking into this a little closer we found that the server had ran out of disk space so after making some space and using “symfony cc” to clear the cache we thought that this would have resolved the problem, however we continued to get the “does not havea  registered handler” message being presented.

In the end, we had to clear the cache manually with a command similar to:-

rm -fr cache/*

For some reason this seemed to work fine where as the “symfony cc” command didn’t work therefore the only conclusion that we could come up with is that when the server ran out of disk space it corrupted something in the symfony cache which either is not normally cleared with a “symfony cc” and as a result we needed to remove it completely so symfony could re-build it automatically.