Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Fix Statement class passing bound objects to SQL logger #127

Merged
merged 4 commits into from May 4, 2012

Conversation

Projects
None yet
3 participants
Contributor

jimcottrell commented Apr 4, 2012

This commit saves converted parameter values in bindValue() so the later call to the SQL logger in execute() will not pass bound objects without type information.

Fix Statement class passing bound parameter objects to SQL logger wit…
…hout type information: save parameter's converted value
Member

stof commented Apr 4, 2012

@jimcottrell what is the issue you are trying to fix ? There is no link to a ticket in the issue tracker and no tests in your pull request

Contributor

jimcottrell commented Apr 4, 2012

@stof I suppose in my mind the issue was pretty clear, but essentially my problem is that if you want to do anything with bound parameters from an SQL logger (besides echo them, of course), Statement provides no type information to the logger. That is, only parameters are saved, not types.

So, if you bind, say, a DateTime object with an appropriate type set, the query itself will run fine because of course the DBAL type system knows what to do, but the logger just gets an object as one of the parameters and no type to tell it what to do with the parameter.

There are really two solutions: 1) save type information as well, or 2) save the converted parameter value. I chose #2 because I'm unconvinced that where SQL logging is concerned the original parameter is as important as what's actually getting passed to the database, but neither option is complicated, and in retrospect, #1 is really the more robust option if people do need to see the original parameter objects when logging. I suppose it depends on whether you consider the purpose of the logging system to record what DBAL sees or what the DB sees when all is said and done.

Looks like issue DBAL-248 was automatically created, if you'd prefer to have this conversation there.

Member

stof commented Apr 4, 2012

@jimcottrell the logger also receives the types

Member

stof commented Apr 4, 2012

@jimcottrell Btw, Symfony2 uses the types of the parameters to be able to store the queries in a serializable way but to try to keep as much as information as possible to be able to run the query again in most cases (well, we don't run the query itself but we explain it): https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Doctrine/DataCollector/DoctrineDataCollector.php#L117

Contributor

jimcottrell commented Apr 4, 2012

@stof

lib/Doctrine/DBAL/Statement.php, line 125:

    public function execute($params = null)
    {
        $logger = $this->conn->getConfiguration()->getSQLLogger();
        if ($logger) {
            $logger->startQuery($this->sql, $this->params);
        }

        ...

There are no types passed here.

Contributor

jimcottrell commented Apr 4, 2012

@stof This is the more robust way to do it then. I'm still a bit new to Git, so if you are interested in pulling this, I'm not sure if it would be best for me to create a new request so that the original commit isn't a part of the history?

Member

stof commented Apr 4, 2012

@jimcottrell you should reset the type at the end of the execute method when the params are reseted.

Contributor

jimcottrell commented Apr 4, 2012

@stof Oops, yes, you're absolutely right about the reset.

beberlei added a commit that referenced this pull request May 4, 2012

Merge pull request #127 from aspendigital/feature-statement-fix
Fix Statement class passing bound objects to SQL logger

@beberlei beberlei merged commit b0f5280 into doctrine:master May 4, 2012

@jimcottrell jimcottrell deleted the aspendigital:feature-statement-fix branch Jan 29, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment