Skip to content

Draft: Ajoute un importeur basé sur Frictionless

Ronan Amicel requested to merge add-frictionless-importer into main

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, 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 validateur as_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).
Edited by Ronan Amicel

Merge request reports