Jdbi: Guide du développeur : migration v2 vers v3

Remarques sur la migration d'un petit projet :

Classes renommées (donc pas aussi simple que de supprimer les importations et de laisser l'IDE le réparer):

• DBI -> Jdbi
• IDBI -> Jdbi
• DBIException -> JdbiException

Les constructeurs de Jdbi ont été remplacés par une méthode de fabrique create() .

ResultSetMapper est remplacé par RowMapper et la méthode map n'a plus l'index de ligne. Une classe nommée ResultSetMapper existe dans Jdbi 3, mais elle sert un objectif différent. @Mapper est remplacé par @UseRowMapper . registerMapper() sur Jdbi est remplacé par registerRowMapper() .

@BindIn est remplacé par @BindList et ne nécessite plus StringTemplate.

Avec la modélisation Jdbi par défaut, les chevrons ne sont pas entre guillemets, ce qui signifie qu'IntelliJ comprend la syntaxe après avoir configuré le Pattern Pattern sous Tools -> Database -> User Patterns .

Query n'a plus un type par défaut de Map et donc list() ne peut pas être appelé directement dessus. Appelez mapToMap() avant d'appeler list() .

TransactionStatus n'existe plus.

TransactionConsumer.useTransaction() ne prend plus qu'un Handle maintenant, donc l'argument TransactionStatus doit être supprimé lors de l'utilisation avec les méthodes useTransaction() sur Jdbi ou Handle .

TransactionCallback.inTransaction() ne prend plus qu'un Handle maintenant, donc l'argument TransactionStatus doit être supprimé lors de l'utilisation avec les méthodes inTransaction() sur Jdbi ou Handle .

CallbackFailedException n'existe plus. Les différentes interfaces fonctionnelles telles que HandleConsumer , HandleCallback , TransactionalConsumer et TransactionalCallback , peuvent désormais lever n'importe quel type d'exception (mais restreintes à l'aide de génériques pour éviter les vérifications inutiles gestion des exceptions).

La prise en charge des objets SQL n'est plus disponible par défaut. Il doit être enregistré pour chaque instance Jdbi créée.

Migrate Refactor d'IntelliJ a été utile pour lancer la migration.

Merci @electrum d'avoir mis cela ensemble ! Ce sera une grande aide

Quelques notes supplémentaires suite à la révision de ma présentation :

• Artefacts renommés org.jdbi:jdbi -> org. jdbi:jdbi3 , :jdbi3-sqlobject, :jdbi3-guava, etc.
• Le package principal a été modifié : org.skife.jdbi.v2 -> org.jdbi.v3. Cela signifie que v2 et v3 peuvent coexister sur un projet pendant que vous migrez
• Renommé : GetHandle -> SqlObject
• Les fabriques d'arguments et de mappeurs v3 utilisent java.lang.reflect.Type , tandis que la v2 utilisait java.lang.Class . Cela signifie que la v3 est capable de gérer des signatures de type générique complexes que la v2 ne pouvait pas.
• Les fabriques d'arguments et de mappeurs v3 et les interfaces fonctionnelles à méthode unique qui renvoient une valeur facultative. v2 avait des méthodes accepts() et build() séparées.
• Les types d'objets SQL dans la v3 ne doivent être que des interfaces publiques, pas de classes. Les types de retour de méthode doivent également être publics. Cela est dû au passage de l'implémentation de SQL Object de CGLIB à java.lang.reflect.Proxy, qui ne prend en charge que les interfaces.
• Les annotations @Bind sur les paramètres de la méthode SQL Object peuvent être rendues facultatives, en compilant votre code avec le drapeau -parameters activé.
• Les objets SQL à la demande ne fonctionnent pas bien avec les méthodes qui renvoient Iterables. Les objets à la demande ferment strictement le handle après chaque appel de méthode et ne "tiennent plus la porte ouverte" pour que vous finissiez de consommer l'itérable comme ils le faisaient dans la v2. Cela exclut une source majeure de fuites de connexion.
• Les objets SQL ne peuvent plus être fermés : ils sont soit à la demande, soit leur cycle de vie est lié au cycle de vie du descripteur auquel ils étaient attachés.
• L'interface StatementLocator est supprimée du noyau. Toutes les instructions principales s'attendent à recevoir le SQL réel maintenant. Un concept similaire, SqlLocator a été ajouté mais uniquement dans le domaine des objets SQL.

Un autre : StatementRewriter a été refactorisé en TemplateEngine et SqlParser .

Le comportement de select est très important à ajouter à la liste. C'est parti de ça :

List<Map<String, Object>> rs = h.select("select id, name from something");

Pour ça:

List<Map<String, Object>> rs = h.select("select id, name from something").mapToMap().list();

Je souhaite que la puissance, la flexibilité et la sécurité supplémentaires de la v3 n'aient pas le prix de la verbosité.

Salut @javajosh , nous n'avons pas considéré que celui-ci était trop mauvais car nous essayons de décourager le mappage vers des objets Map . Si rien d'autre, les règles concernant la sensibilité à la casse pour les clés sont déroutantes. Y a-t-il une raison pour laquelle vous devez émettre un Map plutôt que de créer votre propre type défini ? Personnellement, j'écrirai toujours de petites classes de résultats (en utilisant des mappeurs et des liants constructeur / champ / propriété) et j'éviterai toujours d'utiliser Map . Avez-vous un cas d'utilisation où c'est très pratique?

Salut @stevenschlansker - J'y arrive du point de vue de la "première expérience des développeurs". Le code ci-dessus est tiré de votre propre tutoriel v2, qui, je pense, est admirablement minimaliste. Et en effet, avec un langage hébergé par JVM comme Groovy, qui a une carte intégrée de type javascript, vous verriez probablement plus souvent un résultat non typé.

@javajosh que pensez-vous de https://github.com/jdbi/jdbi/pull/925 ?

@stevenschlansker Vouliez-vous dire #928 ?

@stevenschlansker Certainement une amélioration ! Mais c'est quand même plus verbeux que la v2. :) Ceci s'ajoute à la plus grande verbosité dans maven, etc. Je ne veux tout simplement pas voir JDBI suivre le chemin de JUnit qui a eu du mal à amener les gens à adopter la v4 car il avait de belles fonctionnalités, mais était beaucoup plus compliqué que v3 et v3 étaient "assez bons". J'ai le même sentiment à propos de la syntaxe "withHandle" (bien que je comprenne votre instinct pour éliminer toutes les poignées pendantes).

@javajosh Vous avez toujours Jdbi.open() si vous voulez un meilleur contrôle, bien que nous vous recommandons de l'utiliser dans un bloc try-with-resources pour plus de sécurité.

Début du travail sur les documents de migration v2 vers v3.

@javajosh Revenons à la méthode ResultBearing.list() qui renvoie un List<Map<String,Object>> : je ne suis pas sûr que l'ajout de ceci était une bonne idée, surtout si tard dans le cycle de publication.

Je comprends vos préoccupations concernant la verbosité, mais cette verbosité sert à clarifier l'intention du développeur :

handle.createQuery(sql)
    .mapToMap()
    .list()

est plus clair pour le lecteur que :

handle.createQuery(sql)
    .list()

C'est une chose délicate, et je n'envie pas votre position d'avoir à choisir. JDBI est une belle bibliothèque, et je suis content d'avoir simplement enregistré mes préoccupations concernant la verbosité ; s'il est judicieux d'ajouter une méthode de commodité dans ce cas précis, je n'en suis pas sûr et j'aurais tendance à faire confiance à votre jugement plutôt qu'au mien, car je ne suis pas sérieusement impliqué dans le projet ! Merci pour l'écoute!

Faites-nous savoir si vous trouvez un exemple concret de la façon dont c'est mieux avec un nom plus court, ou une présentation de la façon dont nous pourrions l'améliorer 😄