No generic way to get database backend version

[apollovy@…]

DatabaseWrapper object have to have an API to return version of underlying database backend.
Ex., for MySQL backend there's a get_server_version method, that returns MySQL version. There have to be such methods in other backends, I guess.

[Michael Manfre]

What are you thinking as the generic usage for this? Aside from debug logging, the underlying database version seems to only have value to the backend that may need to behave differently depending on the version. E.g. mssql 2005 does not support microseconds, but 2008 does.

[apollovy@…]

Maybe it've got a specific case, but in our admin interface we always add a block, where user can see, what versions of software is used on their site. It was pretty simple to retreive python and django versions, but no such simplicity for db.

[Anssi Kääriäinen]

I am accepting this ticket, but I think there should be some generic property returning not the server version, but a more generic string explaining the used server backend:

from django.db import connection
print(connection.backend_info)
OUT: PostgreSQL 8.4.11, Psycopg2 2.4.4.

So, this should not aim for programmatic usability (the pg_version is useful for that), instead something that would be usable in for example django-users: "Can you provide your backend info (as reported by connection.backend_info)".

A more generic Django.debug_info could be usable, too, but of course not this ticket's problem. This could include such things as used Python version, OS, backend info for each backend, and of course Django version. This would be pretty useful to require in tickets...

[anonymous]

This bug takes some effort, because we have to implement a function for each backend database. And test for each one. So this pain, to install, connect and check for each database makes the bug less-easy.

[vanessagomes]

• It was added connection.backend_info() that returns the name and the version of the current database. Authors of other backends should implement this in their custom backends. * Use of backend_info: >>> from django.db import connection >>> print (connection.backend_info()) sqlite 3.7.2

[vanessagomes]

An example of use is:

from django.db import connection
print (connection.backend_info()) 
sqlite 3.7.2

The patch only resolve the solution for sqlite3 database. After I'll submit patches for postegresql, and other databases.

[vanessagomes]

Changind the return of backend_info()

[vanessagomes]

New use of backend_info:

   from django.db import connection
   connection.backend_info()
   BackendInfo(vendor='sqlite', version=(3, 7, 2))

[Anssi Kääriäinen]

My idea was that the backend_info would be targeted purely at human users (as a debug/logging info). One main use case from my point of view is "Could you report what DB you are using. You can get it with connection.backend_info()". So, the format I was suggesting was: "SQLite 3.7.2". With maybe also the backend library info, too, for example: "PostgreSQL 8.4.11, Psycopg 2.4.5". Or even "EnterpriseDB 8.4.0, Psycopg 2.4.5"

The namedtuple format is more powerful when used from Python, but as a human readable format it isn't as nice. When printing the backend info for debug purposes, the vendor 'postgresql' should be converted to 'PostgreSQL', or maybe to 'EnterpriseDB'.

Any thoughts on this? I can go with the namedtuple format if that is wanted. I prefer the string format myself. This is mostly bikeshedding now. I will probably go with the namedtuple format if no votes for the string format are given just because that is what is implemented in the patch.

[vanessagomes]

In the first patch I implemented the returning a String, but at #django-dev it was suggested that the return was namedtuples... I think it is more useful if returns a namedtuple.

[Tim Graham]

Patch needs to be updated to apply cleanly.

[Michiel Beijen]

I created a pull request here:

​https://github.com/django/django/pull/8521

I took the old patch attached to this ticket and brushed it up a bit. To the original SQLite implementation I added PostgreSQL, MySQL and Oracle implementations.

We also no longer return a namedtuple but a dict instead because it feels more in line with the rest of Django.

The thing I'm unsure about is if it would not be better to have the 'vendor' be the 'vendor' and a 'type' that can indicate the type. For instance for MySQL there is MySQL and MariaDB with each their own version numbering schemes.

This provides an option

get_backend_info()

that allows you to retrieve the database type (vendor) and version, as a tuple.

>>> from django.db import connection
>>> connection.backend_info()
{'vendor': 'postgresql', 'version': (9, 6, 2)}

[Mariusz Felisiak]

get _database_version() was added in 9ac3ef59f9538cfb520e3607af743532434d1755, and vendor was added in 121d2e36785dc0ce8e7d1c48883fc7b719b21afc. As far as I'm aware we don't need an additional API and this ticket can be marked as "fixed".