Produits Entr'ouvert » Passerelle

Et je découvre qu'avec django-jsonfield, on ne peut pas faire de lookup sur une clé, ie features.filter(data__property=value) ne fonctionne pas. C'est bête, ce code est récent, rien n'empêchait de partir sur le JSONField dans django.contrib.postgres qui supporte très bien ce genre de chose.

Je tente d'ajouter une migration de l'un vers l'autre ? Il y a des précédents ?

FeatureCache.objects.all().filter(data__contains={'ville': 'Bron'}) fonctionne.

Mais oui on peut imaginer la migration, j'ai l'impression qu'en terme de stockage db ça ne change rien. (il y a eu des trucs de cet ordre dans authentic, je crois).

Tout à fait d'accord.

Bon j'ai vu le code dans a2, j'ai pris peur et j'ai essayé la solution simple (migration qui ajoute new_data, RunPython new_data = data, supprime data et renomme new_data -> data) et je me suis pris https://github.com/adamchainz/django-jsonfield/issues/5 en pleine tête (on ne peut pas utiliser le field de postgres tant que le projet utilise django-jsonfield, ce jusqu'à la version 1.3 et on a comme contrainte < 1.3). À part à faire sauter la contrainte de version, je vais revenir au filtrage permis par django-jsonfield...

tant que le projet utilise django-jsonfield

Mais on peut pas juste tout virer ça ? 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).

data__properties__code_insee=..., je préférerais zapper la partie data__properties, limiter la recherche au contenu de la clé properties, et dans la querystring se serait property__code_insee=... (oui, property, pas properties, parce qu'on filtre sur une seule). (j'hésite aussi à proposer property:code_insee plutôt que le double underscore).

        if s.lower() == 'true':
            return True
        if s.lower() == 'false':
            return False

Je ne ferais pas ça pour le moment, côté data.grandlyon il y a quantité de propriétés avec 'true' mis sous forme de chaine (genre "acceshandi": "true").

Dans une évolution où on aurait besoin de filtrer sur base d'un autre type, on pourrait passer par un autre paramètre, genre bool_property__whatever=true.

la clé properties c'est un détail d'implem du serveur

Ça fait partie de la définition du format geojson.

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

Ça fait partie de la définition du format geojson.

Dac je savais pas, ça me va mieux.

Valentin Deniaud a écrit :

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

Je ne ferais pas ça pour le moment, côté data.grandlyon il y a quantité de propriétés avec 'true' mis sous forme de chaine (genre "acceshandi": "true").

Et ça continuait à marcher, les filtres avec les conversions viennent en plus et pas à la place, mais je retire c'est pas beau de toute façon.

Mais je garde bien la tentative de conversion des nombres ?

Mais je garde bien la tentative de conversion des nombres ?

Je n'y avais même pas prêté attention; et je n'arrive même pas à voir dans

        kwargs.update({k: self.cast_str(v) for k, v in kwargs.items() if self.cast_str(v) is not None})

que ça vient en plus et pas à la place; en soit je veux bien, y compris le true/false, et les nombres, mais avec un commentaire là-dessus pour noter l'intention, et un test ajouté pour le filtre sur une valeur numérique/booléenne.