Interfaces, classes abstraites, et stratégies d'héritage

[JabX]

Fix #570

Cette PR introduit la notion de classe abstraites et d'interfaces dans TopModel.

TopModel connaissait jusqu'à présent des classes "abstraites" (via abstract: true), qui étaient en réalité générées comme des interfaces, mais ne permettait pas de les utiliser en tant que telles, et n'étaient utilisées quasiment que pour réaliser des projections avec JPA.

Désormais, vous pouvez renseigner sur une classe :

• type: interface, qui est globalement équivalent à ce qu'était abstract: true avant (qui n'existe plus, vous devrez donc faire un rechercher/remplacer global pour mettre à jour vos déclarations.
  Une interface en revanche maintenant être implémentée par une autre classe, via implements, qui fonctionne un peu comme decorators : vous listez les interfaces que votre classe doit implémenter, les propriétés de l'interface seront recopiées sur la classe et l'interface sera ajoutée à la classe générée.
  Une nouvelle propriété propertySourceOrder vous permet de spécifier dans quel ordre vous souhaitez que vos propriétés soient listées. Par défaut, ce sera [properties, implements, decorators], mais vous pouvez changer cet ordre si vous voulez que les propriétés des interfaces soient listées avant les propriétés définies dans la classe par exemple.

• type: abstract, pour définir une classe abstraite, qui sera générée comme une classe abstraite. TopModel ne fait pas beaucoup de différences avec les classes abstraites, hormis quelques contrôles supplémentaires évidents.

Pour accompagner l'intégration des classes abstraites, vous pouvez désormais spécifier la stratégie d'héritage pour les classes persistées, en accordance avec les stratégies existantes dans les divers ORMs. Les trois valeurs de inheritanceStrategy sont :

• joined-tables : ce que TopModel a toujours fait, avec deux tables en base de donnée avec une jointure entre les deux. A noter qu'une classe abstraite ne peut pas choisir cette stratégie-là.
• single-table, qui crée une unique table pour insérer toutes les instances de la hiérarchie de classe, avec les colonnes supplémentaires de chaque implémentation. Cette stratégie nécessite une colonne de discriminateur avec des valeurs pour chaque type non abstrait de la hiérarchie. Vous avez le choix de :
  • Renseigner ou pas discriminatorProperty sur la classe parente avec une propriété de la classe. Si elle n'est pas renseignée, une colonne technique {trigram}_discriminator sera ajoutée en BDD
  • Renseigner ou pas discriminatorValue sur chaque classe non abstraite de la hiérarchie. Si elle n'est pas renseignée, c'est le nom de la table qui sera utilisé.
• distinct-tables, qui créera une table par classe non abstraite de la hiérarchie, qui contiendra l'ensemble des colonnes de chaque classe (les colonnes de la classe parente seront donc dupliquées sur chaque table). Cette stratégie utilise cependant une seule séquence pour gérer les clés primaires de chaque table.

[codecov-commenter]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️