[Django] #18332: No generic way to get database backend version
Django
----------------------------------------------+--------------------
Reporter: apollovy@… | Owner: nobody
Type: Bug | Status: new
Component: Database layer (models, ORM) | Version: 1.3
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 1 | UI/UX: 0
----------------------------------------------+--------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/18332>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Type: Bug | Status: new
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Changes (by manfre):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:1>
Django
Type: Bug | Status: new
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:2>
Django
Reporter: apollovy@… | Owner:
Type: Bug | mateusgondim
Component: Database layer | Status: assigned
(models, ORM) | Version: 1.3
Severity: Normal | Resolution:
Keywords: | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 1 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by mateusgondim):
* owner: nobody => mateusgondim
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:3>
Django
Type: Bug | Status: new
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Changes (by mateusgondim):
* owner: mateusgondim => nobody
* status: assigned => new
Comment:
Sorry, i thought this one had already been accepted.
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:4>
Django
Type: Bug | Status: new
(models, ORM) | Resolution:
Keywords: | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Changes (by akaariai):
* stage: Unreviewed => Accepted
Comment:
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...
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:5>
Django
Reporter: apollovy@… | Owner:
Type: Bug | vanessagomes
Component: Database layer | Status: new
(models, ORM) | Version: 1.3
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Changes (by anonymous):
* owner: nobody => vanessagomes
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:6>
Django
Reporter: apollovy@… | Owner:
Type: Bug | vanessagomes
Component: Database layer | Status: new
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
Changes (by anonymous):
* easy: 1 => 0
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:7>
Django
Reporter: apollovy@… | Owner:
Type: Bug | vanessagomes
Component: Database layer | Status: new
Keywords: | Triage Stage: Accepted
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* has_patch: 0 => 1
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:8>
Django
Reporter: apollovy@… | Owner:
Type: Bug | vanessagomes
Component: Database layer | Status: new
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by vanessagomes):
New use of backend_info:
{{{
from django.db import connection
connection.backend_info()
BackendInfo(vendor='sqlite', version=(3, 7, 2))
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:9>
Django
Reporter: apollovy@… | Owner:
Type: Bug | vanessagomes
Component: Database layer | Status: new
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:10>
Django
Reporter: apollovy@… | Owner:
Type: Bug | vanessagomes
Component: Database layer | Status: new
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:11>
Django
Reporter: apollovy@… | Owner:
Type: Bug | vanessagomes
Component: Database layer | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* needs_better_patch: 0 => 1
Comment:
Patch needs to be updated to apply cleanly.
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:12>
Django
Reporter: apollovy@… | Owner:
| vanessagomes
Type: Bug | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* version: 1.3 => master
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:13>
Django
Reporter: apollovy@… | Owner:
| vanessagomes
Component: Database layer | Version: 1.3
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by 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)}
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:13>
Django
Reporter: apollovy@… | Owner:
| vanessagomes
Component: Database layer | Version: 1.3
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Adam (Chainz) Johnson (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:14>
Django
Reporter: apollovy@… | Owner: (none)
Type: Bug | Status: assigned
Component: Database layer | Version: 1.3
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: vanessagomes => (none)
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:15>
Django
Reporter: apollovy@… | Owner: (none)
Component: Database layer | Version: 1.3
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:16>
Django
Reporter: apollovy@… | Owner: (none)
Component: Database layer | Version: 1.3
(models, ORM) |
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):
* status: new => closed
* resolution: => fixed
Comment:
`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".
--
Ticket URL: <https://code.djangoproject.com/ticket/18332#comment:17>