Opened 3 years ago

Last modified 15 months ago

#18332 new Bug

No generic way to get database backend version

Reported by: apollovy@… Owned by: vanessagomes
Component: Database layer (models, ORM) Version: 1.3
Severity: Normal Keywords:
Cc: 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 3 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 3 years ago.
Changind the return of backend_info()

Download all attachments as: .zip

Change History (14)

comment:1 Changed 3 years ago by manfre

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 Changed 3 years ago by 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.

comment:3 Changed 3 years ago by mateusgondim

  • Owner changed from nobody to mateusgondim
  • Status changed from new to assigned

comment:4 Changed 3 years ago by mateusgondim

  • Owner changed from mateusgondim to nobody
  • Status changed from assigned to new

Sorry, i thought this one had already been accepted.

comment:5 Changed 3 years ago by akaariai

  • Triage Stage changed from Unreviewed to 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 Changed 3 years ago by anonymous

  • Owner changed from nobody to vanessagomes

comment:7 Changed 3 years ago by anonymous

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

Changed 3 years ago by 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

comment:8 Changed 3 years ago by vanessagomes

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

Changed 3 years ago by vanessagomes

Changind the return of backend_info()

comment:9 Changed 3 years ago by vanessagomes

New use of backend_info:

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

comment:10 Changed 3 years ago by akaariai

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 Changed 3 years ago by 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.

comment:12 Changed 15 months ago by timo

  • Patch needs improvement set

Patch needs to be updated to apply cleanly.

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