Draft: Ajoute un importeur basé sur Frictionless
Contexte
On se pose la question depuis un moment de « frictionlessiser » insitu.
Actuellement, on accepte des descriptions au format Data Package pour les jeux de données, mais on convertit en interne la description au format insitu.
Dans la MR !503 (closed), on a essayé de jouer les transformations frictionless au milieu de l’import insitu, mais ce fonctionnement hybride est source de difficultés.
Dans le cadre du PoC indicastore, on avait fait un mini ETL qui utilisait frictionless pour charger les jeux de données.
Contenu
Précédemment on a introduit une classe abstraite Importer
, avec une implémentation InsituImporter
.
Cette MR ajoute une deuxième implémentation FrictionlessImporter
, qui fonctionne selon le principe suivant :
-
resource.validate()
va lire le fichier et valider sa structure -
resource.transform()
va appliquer les transformations -
resource.publish()
pour charger en base (mécanisme qu’on avait testé dans indicastore)
Ce nouvel importeur sera utilisé si la description du jeu de données est au format Frictionless (Data Package) ET si la clé insitu: importer: frictionless
est présente dans la description. L’utilisation est ainsi en mode opt-in, de manière à éviter les régressions (cf. ci-dessous).
On ajoute aussi une option --engine={insitu|frictionless}
à la commande insitu import
pour forcer l’un ou l’autre et faciliter les essais.
Limitations / régressions
Je m’attends à ce qu’on identifie différents cas où Frictionless est plus strict ou ne gère pas les choses de la même manière qu’insitu.
- Frictionless veut qu’on décrive toutes le colonnes du tableau source, dans le bon ordre, alors qu’insitu se contente de celles que l’on veut importer, et accepte qu’elles soient dans le désordre
- en Table Schema, le type
array
décrit un tableau au format JSON, alors qu’insitu parse une liste de valeurs séparée par une virgule (ou un autre caractère spécifié en paramètre) - par défaut, Frictionless va considérer une cellule vide (
""
) comme une donnée manquante (null
) (cf. la sémantique de missingValue dans Table Schema) alors que dans insitu, le validateuras_string
produira une chaîne vide. - l’utilisation du step
field-split
échoue si une des lignes ne correspond pas au pattern (par exemple si la cellule est vide), alors qu’avec l’importeur insitu (on convertissait ce step vers notre mécanisme de regex) on va être plus tolérant - Frictionless n’a pas de mécanisme pour récupérer la date de dernière modification d’un fichier XLSX (ce que sait faire l’importeur insitu).