[Django] #25454: Problem using HStoreField in django shell
Django
----------------------------------+-------------------------
Reporter: reichert | Owner:
Type: Bug | Status: new
Component: contrib.postgres | Version: 1.8
Severity: Normal | Keywords: hstorefield
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------+-------------------------
Using hstorefield through the webserver works fine, but for applications
that don't use the webserver like management commands we got a problem
with models that use hstorefield. Among these problems is retrieving the
hstorefield object which is retrieved as 'str' insteado of a 'dict'.
I found out a workaround that may be the cause of the bug but I've not
enought knowledge to propose a fix.
Here is how to replicate the problem:
{{{
# subaccount is a hstorefield of AccountEntry model
In [8]: entry = AccountEntry.objects.get(pk=1)
In [9]: entry.subaccount
Out[9]: '"store"=>"velocity"'
In [10]: entry.subaccount.__class__
Out[10]: str
}}}
To get it working I'd to do this trick:
{{{
In [12]: from psycopg2.extras import register_hstore
In [13]: from django.db import connection
In [14]: register_hstore(connection.connection, globally=True,
unicode=True)
In [15]: entry.subaccount
Out[15]: '"store"=>"velocity"'
In [16]: entry2 = AccountEntry.objects.get(pk=2)
In [17]: entry2.subaccount
Out[17]: {u'store': u'velocity'}
In [18]: entry2.subaccount.__class__
Out[18]: dict
}}}
Note that:
1) We are using django 1.8.4, python 2.7.9, psycopg2 2.6.1, postgresql
9.4.4
2) We installed the hstore extension in the template1 and we have created
the django database after the hstore extension creation.
3) We have in our INSTALLED_APPS the django.contrib.postresql
Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/25454>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: reichert | Owner:
Type: Bug | Status: closed
Component: contrib.postgres | Version: 1.8
Severity: Normal | Resolution: needsinfo
Keywords: hstorefield | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by charettes):
* status: new => closed
* needs_better_patch: => 0
* resolution: => needsinfo
* needs_tests: => 0
* needs_docs: => 0
Comment:
Hi reichert,
It looks like `django.contrib.postresql.apps.PostgresConfig.ready` which
is supposed to deal with `register_hstore` is never called.
From what I can see you reproduced using an iPython shell, was it lauched
using `manage.py shell` and if it's not the case did you make sure to call
`django.setup()` to make sure all apps were initialized?
--
Ticket URL: <https://code.djangoproject.com/ticket/25454#comment:1>
Django
Reporter: reichert | Owner:
Type: Bug | Status: new
Component: contrib.postgres | Version: 1.8
Keywords: hstorefield | Triage Stage: Unreviewed
Easy pickings: 0 | UI/UX: 0
Changes (by craigds):
* cc: craig.ds@… (added)
* status: closed => new
* resolution: needsinfo =>
Comment:
I've just had this issue. Reopening because it's marked needsinfo and I
have some :)
For us, we're using `manage.py shell` correctly, but it looks like we're
doing a database query in a silly place in our code _before_ the app cache
is ready.
That is, we're forcing a database connection, which in turn sends the
`connection_created` signal before the `register_hstore` signal handler is
registered by `PostgresConfig.ready`.
This is obviously something dumb we're doing, but it'd be nice if Django
was able to throw an error when the database connection is initialised too
early. Then we would have found this bug ages ago. Would that be possible?
--
Ticket URL: <https://code.djangoproject.com/ticket/25454#comment:2>
Django
Reporter: reichert | Owner:
Type: Bug | Status: new
Component: contrib.postgres | Version: 1.8
Keywords: hstorefield | Triage Stage: Unreviewed
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
I'm not sure if we could do that or not (I think probably a lot of
projects make queries at import time so a warning rather than exception
might be needed), but could you provide a minimal project to reproduce it?
--
Ticket URL: <https://code.djangoproject.com/ticket/25454#comment:3>
Django
Reporter: reichert | Owner:
Type: Bug | Status: new
Component: contrib.postgres | Version: 1.8
Keywords: hstorefield | Triage Stage: Unreviewed
Easy pickings: 0 | UI/UX: 0
Comment (by craigds):
Sure thing. Here's a minimal test project I whipped up:
https://github.com/craigds/django_25454
--
Ticket URL: <https://code.djangoproject.com/ticket/25454#comment:4>
Django
being called
--------------------------------------+------------------------------------
Reporter: reichert | Owner:
Type: Cleanup/optimization | Status: new
Component: contrib.postgres | Version: 1.8
Severity: Normal | Resolution:
Keywords: hstorefield | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* type: Bug => Cleanup/optimization
* stage: Unreviewed => Accepted
Comment:
Thanks, I'll accept the ticket for investigation by an interested person
(could be you if you are so inclined). We can always reclassify it as a
documentation issue if needed.
--
Ticket URL: <https://code.djangoproject.com/ticket/25454#comment:5>
Django
being called
--------------------------------------+------------------------------------
Reporter: reichert | Owner:
Component: contrib.postgres | Version: master
Severity: Normal | Resolution:
Keywords: hstorefield | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by claudep):
* has_patch: 0 => 1
* version: 1.8 => master
Comment:
I am also experiencing this on Django's own test suite when running
postgres_tests.test_hstore.
[https://github.com/django/django/pull/6940 This PR] should solve this.
--
Ticket URL: <https://code.djangoproject.com/ticket/25454#comment:6>
Django
being called
Reporter: reichert | Owner:
Type: | Status: new
Cleanup/optimization |
Component: contrib.postgres | Version: master
Severity: Normal | Resolution:
| checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by charettes):
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/25454#comment:7>
Django
being called
-------------------------------------+-------------------------------------
Type: | Paroz <claude@…>
Cleanup/optimization | Status: closed
Component: contrib.postgres | Version: master
Severity: Normal | Resolution: fixed
Keywords: hstorefield | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Claude Paroz <claude@…>):
* status: new => closed
* owner: => Claude Paroz <claude@…>
* resolution: => fixed
Comment:
In [changeset:"283b468462a586fd9bf7a2794e9b9a20a7e8a2d9" 283b4684]:
{{{
#!CommitTicketReference repository=""
revision="283b468462a586fd9bf7a2794e9b9a20a7e8a2d9"
Fixed #25454 -- Ensured register_hstore_handler is called for all
connections
Thanks Simon Charette for help with the patch.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25454#comment:8>