pdo_mysql with persistent connection

[jeff1985]

While trying to use doctrine with persistent pdo_mysql connections, it seemed that this is not supported.
To be clear, when you pass PDO::ATTR_PERSISTENT => true as config option for connection, an exception will be raised stating that General error: PDO::ATTR_STATEMENT_CLASS cannot be used with persistent PDO instances.

After some research, i found this answer on stackoverflow suggesting to pass a pre-created PDO instance as configuration parameter like this:

$conn = array('pdo' => $dbh);`
$this->entityManager = EntityManager::create($conn, $config);

It does work and my application is able use doctrine as usual. BUT it feels strange. My understanding is that this way we fool doctrine to use pdo without the statement class (which is by the way Doctrine\DBAL\Driver\PDOStatement). Can someone please point out, if there are any risks of using doctrine like that?

I also suggest to add the corresponding info regarding persistent connection to the docs.

[Ocramius]

this way we fool doctrine

Passing in a PDO instance is the correct way to handle edge cases in the configuration DSL of the DriverManager, actually.

[jeff1985]

Yes, but do you need a pdo instance configured to work with Doctrine\DBAL\Driver\PDOStatement? If you don't, then what is the purpose of this class?

[Ocramius]

@jeff1985 doctrine wraps around a number of drivers, and many of them are not PDO-based, so we built internal abstractions to get rid of that impedance.

Doctrine\DBAL\Driver\PDOStatement would still be used.

[jeff1985]

@Ocramius
OK, i understand, why you've built a wrapper class.

You write, that Doctrine\DBAL\Driver\PDOStatement would still be used. How do you mean that? The whole point of providing an own pdo instance is not to be using this class. Because custom statement class is not supported by PDO for persistent connections.

So the actual question is will using the plain \PDOStatement class break any of doctrine code? So far i can see the only change that this class does is to wrap \PDOException with Doctrine\DBAL\Driver\PDOException. As far as i can see, the code still uses \PDOException everywhere, so the change actually would not break anything.

[Ocramius]

will using the plain \PDOStatement class break any of doctrine code?

You have to test that against doctrine's test suite. Doctrine sets the statement in PDOConnection::__construct, so it cannot be worked around at the moment.

I didn't know this:

Because custom statement class is not supported by PDO for persistent connections.

Is there a documentation about it somewhere? Sounds like a weird issue...

[jeff1985]

@Ocramius

Doctrine sets the statement in PDOConnection::__construct, so it cannot be worked around at the moment.

This is not true. We are speaking of a workaround here. PDOConnection is created by PDOMySql\Driver::connect(). The connect() method won't get called, if you've provided a ready pdo instance.

Is there a documentation about it somewhere? Sounds like a weird issue...

It is documented in the php manual:

PDO::ATTR_STATEMENT_CLASS: Set user-supplied statement class derived from PDOStatement. Cannot be used with persistent PDO instances.

[mikemix]

👍 Can't use persistent connection in Doctrine :(

[jeff1985]

@mikemix
What exactly do you mean? Did you read my fist message and the answer on stack overflow?

[mikemix]

I introduced a better solution in my app and used the tick() method in my Ratchet server which pings the connection from time to time.

[jeff1985]

@mikemix
Sorry, but i do not understand. Are you using websockets instead of database? The topic here was how to use persistent connection with doctrine.

[mikemix]

I am using a Doctrine connection in a really long running socket app.

[jeff1985]

@mikemix
so how is that relevant to the topic discussed here?

[mikemix]

After some time the server was useless because the connection to the database was lost?

[jeff1985]

@mikemix
again, how is this relevant? This topic is not about lost connections!

[mikemix]

Prove me wrong I thought this topic was about making a persistent connection to the database with Doctrine.