[JPA] Spring-batch dataFlows, mode JDBC et séparation des values/enums #281, #290, #291

[gideruette]

Spring-batch dataFlows, mode JDBC et séparation des values/enums

Implémentation du générateur de dataflows spring-batch.

Fichiers générés

Flow

Le générateur créé un fichier par dataFlow, comprenant

• Reader
• Writer
• TruncateTasklet éventuellement
• Step
• Flow

La génération s'appuie sur spring-batch, mais aussi la librairie spring-batch-bulk, qui permet des performances exceptionnelles grâce à l'utilisation du bulk insert postgres (avec la commande COPY)

Reader

Le reader privilégié est le reader JdbcCursorItemReaderBuilder. Il permet d'obtenir les meilleures performances, et offre une meilleure flexibilité (choix de la source de données, requête).

Replace

Le truncate se fait avec la classe TaskletQuery de la librairie spring-batch-bulk. Nous aurions pu utiliser un deleteAll mais il est nettement moins performant que le truncate ;)

Processor

Si la classe source et la classe cible sont différentes, un processor est ajouté pour appeler le mapper de l'une vers l'autre

Writer

Les writers utilisent le PgBulkWriter de la librairie spring-batch-bulk. Il existe deux modes

Insert

Le writer copy directement les données dans la table cible. TopModel génère le mapping permettant de faire cette insertion.

Upsert

Le writer copy les données dans une table temporaire, puis recopie les données de table à table. En cas de conflit sur la clé primaire, un update est effectué. TopModel génère le mapping permettant de faire cette insertion.

Job

Le générateur créé un fichier de configuration de job par module. Ce job ordonnance les lancement des flow selon ce qui a été paramétré dans avec les mots clés dependsOn. Il import les configurations nécessaires à son bon fonctionnement.

Limitations et mises en garde

• Ne fonctionne que de base à base
• La base cible ne peut être qu'une base de données Postgresql
• Il est obligatoire de définir un dbSchema
• Mult-source non supporté
• Mode partial non supporté
• Un mapper doit exister de la classe source vers la classe cible (sauf s'il s'agit de la même classe)
• Deux jobs ne peuvent pas dépendre l'un de l'autre s'ils ne sont pas dans le même module
• Prenons les flow A, B, C et D, i C dépend de A et B et D dépend de A, alors D ne se lancera qu'après A et B (alors qu'en théorie il pourrait se lancer directement après A).

Breaking Changes :

• Suppression de la classe imbriquée [Nom de la classe].Values pour les listes de ref
  • En remplacement du getEntity, récupérer l'instance soit avec le constructeur new [Nom de la classe]([élément du type de la clé primaire]), soit directement avec l'instance statique de la classe [Nom de la classe].[Clé de l'instance]
  • En remplacement du type de la clé primaire, une enum [Nom de la classe][Nom de la clé primaire] est générée au chemin spécifié dans la config : enumsPath

Fix: #281 #290 #291