Création de données flyway

Le problème à éviter est de manipuler des données alors que la base n'est pas dans la bonne version.
Par exemple un script exécuté avant la modification du schéma de la base (utilisation d'une colonne qui est déjà supprimée).

Données crées via des scripts SQL

Problème

• Un script projet crée des données du produit et arrive après la modification de la base (script dans le contexte du projet).
  • V1 Création de la table => SQL (produit)
  • V2 Modification du schéma => SQL (produit)
  • V3 Insertion de données => SQL (projet)
    • KO car le schéma est déjà modifié
• On peut retrouver le même problème avec le callbak beforeMigrate qui sera utilisé dans plusieurs scripts.
  • Si une modification de schéma entraine une modification du script
  • Les scripts réalisé avant la modification ne passeront pas

Solution

• Exécuter les scripts flyway utilisant des ordres SQL dans le contexte de la données
  • Script du core dans le core à la bonne place
  • *OK Solution décrite dans le tutoriel de développement* mais pas suffisante pour avoir un mécanisme générique (beforeMigrate)

Données crées via des services Java

Le projet utilise alors les beans et donc le schéma (nom des colonnes par exemple) de la version déployée.

Problème

• un script projet crée des données du produit (libellé, actualité...)et est placé dans le contexte du produit. Le script sera donc exécuté avant que la modification du schéma soit effectuée
  • V1 Création de la table => SQL (produit)
  • V2 Insertion de données => Utilisation des services (produit)
    • KO car les services prennent en compte le schéma déjà modifié.
  • V3 Modification du schéma => SQL (produit)

Solution

• Exécuter les script flyway utilisant des services à la fin de la migration
  • V1 Création de la table => SQL (produit)
  • V2 Modification du schéma => SQL (produit)
  • V3 Insertion de données => Utilisation des services
    • OK car le schéma est déjà modifié
• Exécuter une nouvelle migration de manière programmatique
  • Exécution via AbstractBeanManager
    • Ajout de la location des scripts à exécuter via un listToAddBean pour respecter l'ordre d'insertion la première fois.
    • bean flyway dédié pour éxécuter les script dans un package dédié
      • com.kosmos.ksup.migration
      • Tous les scripts s'y trouvent
      • script repetable (pas de gestion de version à réaliser)
      • Ca va créer une nouvelle table qui sera SCHEMA_VERSION_KSUP
  • Solution à implémenter