Opened 12 years ago

Closed 2 years ago

#18332 closed Bug (fixed)

No generic way to get database backend version

Reported by: apollovy@… 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)

ticket18332.diff (2.3 KB ) - added by vanessagomes 12 years ago.
* 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
ticket18332-patch2.diff (3.7 KB ) - added by vanessagomes 12 years ago.
Changind the return of backend_info()

Download all attachments as: .zip

Change History (17)

comment:1 by Michael Manfre, 12 years ago

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.

comment:2 by apollovy@…, 12 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 Anssi Kääriäinen, 12 years ago

Triage Stage: UnreviewedAccepted

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 anonymous, 12 years ago

Owner: changed from nobody to vanessagomes

comment:7 by anonymous, 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 vanessagomes, 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 vanessagomes, 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.

by vanessagomes, 12 years ago

Attachment: ticket18332-patch2.diff added

Changind the return of backend_info()

comment:9 by vanessagomes, 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 Anssi Kääriäinen, 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 vanessagomes, 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 Tim Graham, 10 years ago

Patch needs improvement: set

Patch needs to be updated to apply cleanly.

comment:13 by Michiel Beijen, 7 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 Adam Johnson, 5 years ago

Cc: Adam Johnson added

comment:15 by Mariusz Felisiak, 3 years ago

Owner: vanessagomes removed
Status: newassigned

comment:16 by Mariusz Felisiak, 3 years ago

Status: assignednew

comment:17 by Mariusz Felisiak, 2 years ago

Resolution: fixed
Status: newclosed

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".

Note: See TracTickets for help on using tickets.
Back to Top