Opened 13 years ago
Closed 2 years ago
#18332 closed Bug (fixed)
No generic way to get database backend version
Reported by: | Owned by: | ||
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.3 |
Severity: | Normal | Keywords: | |
Cc: | Adam Johnson | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
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.
Attachments (2)
Change History (17)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
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.
comment:5 by , 12 years ago
Triage Stage: | Unreviewed → Accepted |
---|
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...
comment:6 by , 12 years ago
Owner: | changed from | to
---|
comment:7 by , 12 years ago
Easy pickings: | unset |
---|
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.
by , 12 years ago
Attachment: | ticket18332.diff added |
---|
- 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
comment:8 by , 12 years ago
Has patch: | set |
---|
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.
comment:9 by , 12 years ago
New use of backend_info:
from django.db import connection connection.backend_info() BackendInfo(vendor='sqlite', version=(3, 7, 2))
comment:10 by , 12 years ago
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.
comment:11 by , 12 years ago
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.
comment:12 by , 10 years ago
Patch needs improvement: | set |
---|
Patch needs to be updated to apply cleanly.
comment:13 by , 8 years ago
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)}
comment:14 by , 5 years ago
Cc: | added |
---|
comment:15 by , 3 years ago
Owner: | removed |
---|---|
Status: | new → assigned |
comment:16 by , 3 years ago
Status: | assigned → new |
---|
comment:17 by , 2 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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".
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.