Produits Entr'ouvert » Passerelle

À la suite du début des discussions dans #42008,

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

Il me semble qu'on ne fait vraiment rien de particulier, qu'il n'y aurait même pas besoin de migration (juste traffiquer une précédente pour faire croire qu'on a depuis toujours utiliser le jsonfield de django.contrib.postgres).

Il y a effectivement pas grand chose à faire, mais au moins un ALTER TABLE, pour changer le type de la colonne de json à jsonb.

Une manière de faire déjà un peu lourde est présentée ici https://tech.polyconseil.fr/migrating-from-json-to-jsonb.html.

Mais, c'est déjà jsonb : (j'ai regardé la prod, et chez moi) (?)

                     Table « passerelle_xxx.opengis_featurecache »
 Colonne  |          Type           |                             Modificateurs                             
----------+-------------------------+-----------------------------------------------------------------------
 id       | integer                 | non NULL Par défaut, nextval('opengis_featurecache_id_seq'::regclass)
 lat      | double precision        | non NULL
 lon      | double precision        | non NULL
 data     | jsonb                   | non NULL
 query_id | integer                 | non NULL
 text     | character varying(2048) | non NULL

OK, je comprends pas le pourquoi du comment, peut-être que Benj en saura plus.

dans django-jsonfield:

    def db_type(self, connection):
        if connection.vendor == 'postgresql':
            # Only do jsonb if in pg 9.4+
            if connection.pg_version >= 90400:
                return 'jsonb'
            return 'text'

Heureusement qu'on n'a pas du text en prod :)

Et bien sûr, si il existe une prod datant d'avant postgres 9.4 ça va exploser en mille morceau, mais peut-être que c'est imaginable de corriger à la main/faire tourner un script dans ces cas là.

On peut imaginer une migration qui assure que c'est déjà jsonb, qui fasse le changement sinon ? Parce que ça va arriver et c'est quand même bien plus facilement gérable partout si c'est géré via une migration.

   Table « passerelle_vincennes_entrouvert_com.csvdatasource_csvdatasource »
     Colonne      |          Type          |        Modificateurs                                                   
------------------+------------------------+------------------------------
 id               | integer                | non NULL Par défaut, ...
 title            | character varying(50)  | non NULL
 slug             | character varying(50)  | non NULL
 description      | text                   | non NULL
 csv_file         | character varying(100) | non NULL
 columns_keynames | character varying(256) | non NULL
 skip_header      | boolean                | non NULL
 _dialect_options | text                   |                   <-----------------
 sheet_name       | character varying(150) | non NULL

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

On peut imaginer une migration qui assure que c'est déjà jsonb, qui fasse le changement sinon ? Parce que ça va arriver et c'est quand même bien plus facilement gérable partout si c'est géré via une migration.

Oui donc on retombe tout à fait sur la méthode du billet de blog cité plus haut, sauf qu'on s'autorise de changer le code et la db en même temps.

Tu écris une migration donc pour être sûr que je ne me lance pas sur une fausse piste, on parle d'écrire à la mano une dizaine de fichiers de migrations, soit un par app qui utilise un jsonfield, à base de RunSQL ?

Tu écris une migration donc pour être sûr que je ne me lance pas sur une fausse piste, on parle d'écrire à la mano une dizaine de fichiers de migrations, soit un par app qui utilise un jsonfield, à base de RunSQL ?

Oui; en modérant le côté "une dizaine de fichiers", genre en créant notre propre classe de EnsureJsonbType(Operation), pour tout à fait réduire la duplication, genre ces migrations seraient juste :

    operations = [
          EnsureJsonbType(model_name='csvdatasource', field_name='_dialect_options'),
    ]

Si ça te semble possible, oui un test pour la migration de passerelle/utils/db.py ce serait super, mais si c'est galère parce que ça oblige à sortir de l'ORM pour traffiquer la DB, on peut juste être très attentif en relisant...

(mais il faut ajouter l'entête de licence au fichier)

reversible = False

Je mettrais True, et un backwards qui ne fait rien vu que ça vivait déjà très bien en jsonb; non ?