#25476: bug in array handling hit in get_constraints() for psycopg2?
-------------------------------------+-------------------------------------
Reporter: heasus | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 1.8
(models, ORM) |
Severity: Normal | Resolution:
Keywords: psycopg2 fetchall | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by heasus):
{{{
Are our environments similar?
% python -V
Python 3.4.3
% pip freeze
Django==1.8.4
django-postgresql==0.0.3
psycopg2==2.6.1
%psql things
things=# \encoding
UTF8
It is indeed empty in get_constraints and, as best I could follow it
through with the debugger, it is empty when it returns from psycopg. But,
running the sql manually or with the test script below produces the
expected output.
things=# SELECT
kc.constraint_name,
kc.column_name,
c.constraint_type,
array(SELECT table_name::text || '.' || column_name::text
FROM information_schema.constraint_column_usage
WHERE constraint_name = kc.constraint_name)
FROM information_schema.key_column_usage AS kc
JOIN information_schema.table_constraints AS c ON
kc.table_schema = c.table_schema AND
kc.table_name = c.table_name AND
kc.constraint_name = c.constraint_name
WHERE
kc.table_schema = 'public' AND
kc.table_name = 'things'
ORDER BY kc.ordinal_position ASC;
constraint_name | column_name | constraint_type | array
---------------------+-------------+-----------------+----------------
things_child_fkey | child | FOREIGN KEY | {children.idx}
things_sibling_fkey | sibling | FOREIGN KEY | {children.idx}
(2 rows)
import psycopg2
conn = psycopg2.connect("dbname=things")
curs = conn.cursor()
curs.execute("""SELECT
kc.constraint_name,
kc.column_name,
c.constraint_type,
array(SELECT table_name::text || '.' || column_name::text
FROM information_schema.constraint_column_usage
WHERE constraint_name = kc.constraint_name)
FROM information_schema.key_column_usage AS kc
JOIN information_schema.table_constraints AS c ON
kc.table_schema = c.table_schema AND
kc.table_name = c.table_name AND
kc.constraint_name = c.constraint_name
WHERE
kc.table_schema = 'public' AND
kc.table_name = 'things'
ORDER BY kc.ordinal_position ASC;
""")
print(curs.fetchone())
print(curs.fetchone())
print(curs.fetchone())
print(curs.fetchone())
% python arraytest.py
('things_child_fkey', 'child', 'FOREIGN KEY', ['children.idx'])
('things_sibling_fkey', 'sibling', 'FOREIGN KEY', ['children.idx'])
None
None
in pdb:
% ./manage.py inspectdb
# This is an auto-generated Django model module.
# You'll have to do the following manually to clean this up:
# * Rearrange models' order
# * Make sure each model has one field with primary_key=True
# * Remove `managed = False` lines if you wish to allow Django to
create, modify, and delete the table
# Feel free to rename the models, but don't rename db_table values or
field names.
#
# Also note: You'll have to insert the output of 'django-admin sqlcustom
[app_label]'
# into your database.
from __future__ import unicode_literals
from django.db import models
class Children(models.Model):
> /home/www/beerdb_debug/lib/python3.4/site-
packages/django/db/backends/postgresql_psycopg2/introspection.py(163)get_constraints()
-> for constraint, column, kind, used_cols in cursor.fetchall():
(Pdb)
(Pdb) n
> /home/www/beerdb_debug/lib/python3.4/site-
packages/django/db/backends/postgresql_psycopg2/introspection.py(165)get_constraints()
-> if constraint not in constraints:
(Pdb) p used_cols
[]
(Pdb)
I'm not proficient in python; I may be missing an obvious fix. I've also
tried the git HEAD, which appears to have its own issues with timezones
that I hacked around to test. I've also tried python 2.7 and on Debian.
I'm happy to try other variations of the environment.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25476#comment:10>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.75a451a4af3938f874aa916d2879ab2a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
