Modifie le comportement de fold / alphanumerize pour se rapprocher de celui de Grist
Le problème
Aujourd'hui, insitu ne fait pas la différence entre une colonne appelée Commune
et une colonne appelée Commune(*)
dans la donnée source. C'est un souci car on rencontre souvent des colonnes de ce type dans les données issues du requeteur de Chorus (le logiciel de facturation de l'Etat). Par exemple, les fichiers reçus de l'ANAH dans la contexte des PVD présentent tous ce cas de figure.
Au dernier trimestre, on avait modifié tous les fichiers source à la main pour supprimer la colonne Commune
et ne garder que l'autre. On pourrait aussi demander à l'ANAH de supprimer ces colonnes de leurs exports mais potentiellement ça veut dire leur imposer un travail manuel juste pour nous l'épargner.
Ma solution
Le comportement de Grist pour créer des id de colonne propres à partir de nom de colonnes potentiellement pleines de caractères spéciaux est selon moi plus robuste. Elle consiste à remplacer les caractères qui ne sont pas dans [A-Za-z1-9_]
par des _
(au maximum un en bout de chaine de caractères, et aucun en début de chaine).
Implémentation
- J'ai modifié le comportement de
alphanumerize
(et donc defold
) pour reproduire celui de Grist - J'ai mis à jour les tests associés
-
fold
est aussi utilisé par les validateursparse_true
etparse_false
, et j'ai découvert un peu par hasard que les anciens tests ne passaient que par chance car on leur passait des strings au lieu de leur passer des listes. J'ai corrigé ces tests.
WDYT ?