How to get driver version in dbal 3.x

[I-Valchev]

Hey! I'm trying to get the driver name, client version and server version of a connection. In dbal 2.x, this used to be possible as used here:

https://github.com/bolt/core/blob/master/src/Doctrine/Version.php#L29-L48

But, since the deprecation of PDOConnection, that no longer works. What's the proper way of making this work with 3.x?

Thanks!

[greg0ire]

You can use use PDO\Connection::getWrappedConnection() to get a PDO instance. So $connection->getWrappedConnection()->getWrappedConnection()

But be wary of https://github.com/doctrine/dbal/pull/4966

[bobdenotter]

[bobdenotter]

That sounds.. fragile at best.

Is there another recommended way to get the driver name / client version, that we might not be aware of?

[morozov]

What is the use case where you need the client version and what is it in the context of the DBAL?

[greg0ire]

The 2 first seem to be about giving info about the current installation in CLI or via HTTP (hopefully the latter one is only available on the dev env, otherwise it's a security issue). That should be obtained form application configuration as pointed out in https://github.com/doctrine/dbal/pull/4086.

The 2 last seem to be 2 hacks about executing different SQL functions based on the platform such as RAND(0|1|2) or JSON_GET_TEXT() / JSON_EXTRACT().

[bobdenotter]

(hopefully the latter one is only available on the dev env, otherwise it's a security issue)

You have to be logged in as a user with administration privileges to see this, yes.

The 2 last seem to be 2 hacks about executing different SQL functions based on the platform such a

If you have suggestions on how we could do these things better in a platform-agnostic way, we're all ears 😇

[greg0ire]

If you have suggestions on how we could do these things better in a platform-agnostic way, we're all ears innocent

I don't, sorry, but you could migrate to instanceof checks (a bit like you already did in https://github.com/bolt/core/blob/3f4c636e9f3855327d97988a7a9bc5cec812bf9c/src/Doctrine/Version.php#L69-L71). That way you don't need to unwrap the connection.

[morozov]

I see that there has been a lot of information exchange on how to make the code work the same as it used to with 2.x but I still don't understand what problem you're trying to solve. Let's pause a little bit and discuss the problem, please.

[bobdenotter]

@morozov We're tyring to get details about the current connection. We do this for two reasons:

• Either so we can output some information to the user, to potentially help troubleshoot
• or to be able to do different things, depending on whether we're currently using SQLite, Postgres or MySQL

[morozov]

@bobdenotter could you be more specific? For instance, you know that the user uses a PDO MySQL driver version x.y.z. How do you use this information? How is it different than if they were using version a.b.c?

[bobdenotter]

@morozov Bolt is a CMS, so our users are not always that tech savvy.

Being able to ask them "Run bin/console bolt:info and paste the output" is a great help, often.

Also, even if the user knows, that doesn't help in making a piece of functionality work that has a different syntax on different DB platforms.

[derrabus]

A library or application that uses DBAL for a unified database access still needs to produce SQL statements that the database it is connected to understands. While standard SQL works for many tasks just fine, there are situations where knowing the database vendor and server version is imperative for emitting the correct SQL statements.

DBAL internally uses the concept of platform classes to compensate for the differences among SQL dialects. So in a way, we already acknowledge that the concern exists. I don't see much harm in allowing a library or application to query information on the database engine and version through a stable and standardized interface.

[morozov]

@derrabus are you answering me or the author of the issue? How is the SQL portability related to the driver version?

I don't see a problem in introducing an API for that, I'm asking how it's expected to be used and what data it should return.

@bobdenotter I haven't gotten an answer to my question, so I cannot help you. BTW, you can get access to the underlying PDO connection via Connection::getNativeConnection() introduced in https://github.com/doctrine/dbal/pull/5037.

[derrabus]

@derrabus are you answering me or the author of the issue?

I'm throwing in my thoughts on topic. 🙂

How is the SQL portability related to the driver version?

It isn't. You need database engine and server version for this and this is part of what is being queried in the code snippet the OP shared. Getting the server version is also becoming harder if we deprecate getWrappedConnection().

I have no strong opinions on the driver version, really. getNativeConnection() might already be the answer here.

[stof]

• or to be able to do different things, depending on whether we're currently using SQLite, Postgres or MySQL

for that, the right approach is to check the database platform, not the wrapped connection

[morozov]

Closing as there's no understanding of what problem the requested feature is supposed to solve, nor how exactly it's expected to work. It is still possible to have the behavior of DBAL 2.x by using the native connection.

[bobdenotter]

Sorry to read this issue is getting closed without resolution.. I'm not sure how i can explain any more clear what our usecase is.. :-/

[morozov]

@bobdenotter the resolution is not to implement any additional API in the DBAL. It is still possible to get the PDO-specific details of the connection via Connection::getNativeConnection() (#5037).

[bobdenotter]

@morozov Ah, thanks! That will be available when 3.3.0 is released, right?

[morozov]

@bobdenotter yes, right.

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.