When getting a value from the database, if using postgresql's JSONB, the value is already an object.
This causes from_db_value as written to fail, since it assumes the database value is a string that can be a JSON-deserializable string. This causes the json.loads to fail, since the value returned from the database is the already-deserialized object.
This adds a check if it the database value a string before attempting to deserialize it - if it's not a string, return the value as-is.
I wonder if we shouldn't just change the code to not create "jsonb" fields... Right now I have a problem where a migration converting a TextField into a JSONField doesn't work and I assume it's because jsonfield wants a "jsonb" field as soon as we have a version of postgres which support that type.
As you explain, someone really interested in what the "jsonb" type brings would use django.contrib.postgres.
Otherwise we should look if one of the other parameters (expression, context) let us discover the underlying type and use that information to decide. I also wonder if the version of pyscopg2 plays a role here. I guess that's the reason why we get something else than a string in the first place...
Except that django-jsonfield will never create a fielt of "json" type. It's either "jsonb" or "text":
defdb_type(self,connection):ifconnection.vendor=='postgresql':# Only do jsonb if in pg 9.4+ifconnection.pg_version>=90400:return'jsonb'return'text'ifconnection.vendor=='mysql':return'longtext'ifconnection.vendor=='oracle':return'long'return'text'
So that trick is only needed if you created the field with a very old version jsonfield when the "jsonb" type did not exist in Postgres yet. I would suggest to solve your problem by upgrading your field to jsonb...