Produits Entr'ouvert » Authentic 2

Mais côté django-jsonfield, ce qui a amené ce code "configure_database_connection", c'est ce commit :

# Node ID 221c256824d495bde6dba17a66b0beeaa56287de

Configure PostgreSQL backend to not do JSON decoding

With Psycopg >= 2.5.4, "jsonb" fields are returned directly under a
decoded form and we are not ready for that. Use
psycopg2.extras.register_default_jsonb() to disable this behaviour on
Django managed connections.

On est en jessie avec 2.5.4, ne va-t-on ainsi pas s'exposer au problème ?

Frédéric Péters a écrit :

Mais côté django-jsonfield, ce qui a amené ce code "configure_database_connection", c'est ce commit :

[...]

On est en jessie avec 2.5.4, ne va-t-on ainsi pas s'exposer au problème ?

Ça veut juste dire qu'actuellement en jessie, django-jsonfield ne fonctionne pas (indépendamment de mon code), ou alors je ne comprends pas leur message de commit.

Si django-jsonfield 0.9.19 et psycopg2 2.5.4 sont incompatibles et c'est ce qu'on a en jessie, à moins que nous ou Debian ait mis un fix dans le packaging de django-jsonfield, ça ne doit pas bien marcher (toujours avec mon code ou pas).

    def to_python(self, value):
        if isinstance(value, six.string_types):

Ça semble ok, géré par ce to_python() qui traite les deux, qui a été retiré dans django-jsonfield 1.0 (via la révision 299).

Mais curieux alors de la migration passant les colonnes en jsonb, parce qu'à regarder montpellier.dev c'est déjà le cas, il y a quelle situation où on avait des colonnes "text" avant ?

                               Table « idp_montpellier_dev_entrouvert_org.authentic2_auth_oidc_oidcprovider »
          Colonne           |           Type           |                                   Modificateurs                                    
----------------------------+--------------------------+------------------------------------------------------------------------------------
 (...)
 jwkset_json                | jsonb                    | 

Frédéric Péters a écrit :

[...]

Ça semble ok, géré par ce to_python() qui traite les deux, qui a été retiré dans django-jsonfield 1.0 (via la révision 299).

Je pense que c'est limit dans le cas d'un champs JSON contenant directement un objet JSON de type chaîne, ce qu'on ne fait jamais en fait.

Mais curieux alors de la migration passant les colonnes en jsonb, parce qu'à regarder montpellier.dev c'est déjà le cas, il y a quelle situation où on avait des colonnes "text" avant ?

Tu parles de la migration post_migrate que je pose dans mon code support Dj1.11/django-jsonfield ? C'est plus pour migrer de json vers jsonb je pense, ça fait un moment que django-jsonfield gérait les colonnes natives de postgres, juste il ne sait pas passer de json à jsonb tout seul bien que ce soit indolore, le simple changement de type de champ Django (TextField -> JSONField) sera géré par le système de migration par contre, mon code ne sert à rien dans ce cas (il verra tout de suite la colonne dans le bon type si tout se passe bien).

Frédéric Péters a écrit :

Tu parles de la migration post_migrate que je pose dans mon code support Dj1.11/django-jsonfield ?

Yep, et ce n'est pas encore clair pour moi quand il est utile, mais bon, ce n'est pas l'objet de ce ticket.

Quand on passe d'une version de postgres qui ne gère pas jsonb à une qui le gère et qu'on est encore en django-jsonfield.