something that’s been bothering me is that CDbCommand::execute() logs errors itself. Shouldn’t that rather be done by the raised CDbException? The reason is that when you catch an exception yourself, execute() will still log the error. A typical example however is when you want to insert a row that might already exist, so you try executing the insert and catch any exception. It’s not good if this is logged as an error, in particular if one has thousands such attempts.
Is there any reason not to move the logging into the exception?
And to make things much worse, for some reason I cannot comprehend, _connection is declared private, not protected, so one cannot just extend CDbConnection and change execute().
Is there a reason why so many things are private instead of protected? I think this is the wrong use of visibility. I had quite some annoying issues with extending the locale functionality too.
You can override CDbConnection very easily. Just write your replacement and set the ‘class’ property of your database config to your new class. For example:
'class' => 'DbConnection',
'connectionString' => $connectionString,
I have overridden both this and the CDbTransaction classes for a history logging solution.
If you mean that you wish to extend CDbCommand, you can also do this, and just override the createCommand() method in your new DbConnection class to return the correct class.
Thanks for your reply, I already do that, but I don’t see how that would help me. CDbCommand::_connection is private, so I cannot access it. I need to however if I want to rewrite execute().
OK, I added an issue on github. I think this is actually a bug, it is wrong to log "errors" when you are handling a caught exception – after all, how else can you possibly, for example, insert rows and ignore possible errors that come from the row already existing.