Jdbi: Entwicklerhandbuch: Migration von v2 zu v3

Hinweise zur Migration eines kleinen Projekts:

Umbenannte Klassen (also nicht ganz so einfach wie Importe löschen und die IDE reparieren lassen):

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

Die Konstruktoren für Jdbi wurden durch eine Fabrikmethode create() ersetzt.

ResultSetMapper wird durch RowMapper ersetzt und die Methode map hat keinen Zeilenindex mehr. Eine Klasse namens ResultSetMapper existiert in Jdbi 3, aber sie dient einem anderen Zweck. @Mapper wird durch @UseRowMapper ersetzt. registerMapper() auf Jdbi wird durch registerRowMapper() ersetzt.

@BindIn wird durch @BindList ersetzt und erfordert kein StringTemplate mehr.

Bei der standardmäßigen Jdbi-Vorlage werden spitze Klammern nicht in Anführungszeichen gesetzt, was bedeutet, dass IntelliJ die Syntax versteht, nachdem Sie das Parametermuster unter Tools -> Database -> User Patterns konfiguriert haben.

Query hat nicht mehr den Standardtyp Map und daher kann list() nicht direkt darauf aufgerufen werden. Rufen Sie mapToMap() an, bevor Sie list() anrufen.

TransactionStatus existiert nicht mehr.

TransactionConsumer.useTransaction() akzeptiert jetzt nur Handle , daher muss das Argument TransactionStatus entfernt werden, wenn dies mit den Methoden useTransaction() auf Jdbi oder verwendet wird Handle .

TransactionCallback.inTransaction() akzeptiert jetzt nur Handle , daher muss das Argument TransactionStatus entfernt werden, wenn dies mit den Methoden inTransaction() auf Jdbi oder verwendet wird Handle .

CallbackFailedException existiert nicht mehr. Die verschiedenen funktionalen Schnittstellen wie HandleConsumer , HandleCallback , TransactionalConsumer und TransactionalCallback können jetzt jeden Ausnahmetyp auslösen (jedoch eingeschränkt durch Generika, um unnötige Überprüfungen zu vermeiden Ausnahmebehandlung).

Die Unterstützung von SQL-Objekten ist standardmäßig nicht mehr verfügbar. Es muss jede erstellte Jdbi Instanz registriert werden.

Der Migrate Refactor von IntelliJ war hilfreich, um die Migration anzukurbeln.

Danke @electrom für die Zusammenstellung! Das wird eine große Hilfe sein

Einige zusätzliche Anmerkungen aus der Überprüfung meiner Präsentation:

• Artefakte umbenannt in org.jdbi:jdbi -> org. jdbi:jdbi3 , :jdbi3-sqlobject, :jdbi3-guave usw
• Kernpaket geändert: org.skife.jdbi.v2 -> org.jdbi.v3. Das bedeutet, dass v2 und v3 während der Migration in einem Projekt koexistieren können
• Umbenannt in: GetHandle -> SqlObject
• v3-Argument- und Mapper-Factorys verwenden java.lang.reflect.Type , während v2 java.lang.Class verwendet. Das bedeutet, dass v3 im Gegensatz zu v2 komplexe generische Typsignaturen handhaben kann.
• v3-Argument- und -Mapper-Factorys und funktionale Einzelmethodenschnittstellen, die eine optionale zurückgeben. v2 hatte separate Accept()- und Build()-Methoden.
• SQL-Objekttypen in v3 dürfen nur öffentliche Schnittstellen sein – keine Klassen. Rückgabetypen von Methoden müssen ebenfalls öffentlich sein. Dies liegt daran, dass die SQL-Objektimplementierung von CGLIB auf java.lang.reflect.Proxy umgestellt wurde, das nur Schnittstellen unterstützt.
• @Bind Anmerkungen zu Methodenparametern von SQL-Objekten können optional gemacht werden, indem Sie Ihren Code mit aktiviertem -parameters -Flag kompilieren.
• On-Demand-SQL-Objekte spielen nicht gut mit Methoden, die Iterables zurückgeben. On-Demand-Objekte schließen das Handle strikt nach jedem Methodenaufruf und „halten die Tür nicht mehr offen“, damit Sie das Iterable fertig verbrauchen können, wie dies in v2 der Fall war. Dies schließt eine Hauptquelle von Verbindungslecks aus.
• SQL-Objekte können nicht mehr geschlossen werden – sie sind entweder bedarfsgesteuert oder ihr Lebenszyklus ist an den Lebenszyklus des Handles gebunden, an das sie angehängt wurden.
• Die Schnittstelle StatementLocator wurde aus dem Kern entfernt. Alle Kernanweisungen erwarten jetzt den Empfang des eigentlichen SQL. Ein ähnliches Konzept, SqlLocator , wurde hinzugefügt, jedoch nur im Bereich der SQL-Objekte.

Noch eins: StatementRewriter wurde in TemplateEngine und SqlParser umgestaltet.

Sehr wichtig, um der Liste hinzugefügt zu werden, ist das Verhalten von select. Daraus ging hervor:

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

Dazu:

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

Ich wünschte, die zusätzliche Leistung, Flexibilität und Sicherheit von v3 wäre nicht mit dem Preis der Ausführlichkeit verbunden.

Hallo @javajosh , wir fanden das nicht besonders schlimm, weil wir versuchen, die Zuordnung zu Map Objekten zu verhindern. Nicht zuletzt sind die Regeln zur Groß- und Kleinschreibung für die Schlüssel verwirrend. Gibt es einen Grund, warum Sie ein Map ausgeben müssen, anstatt einen eigenen definierten Typ zu erstellen? Ich persönlich werde immer kleine Ergebnisklassen schreiben (mit Konstruktor-/Feld-/Property-Mappern und Bindern) und die Verwendung Map immer vermeiden. Haben Sie einen Anwendungsfall, bei dem es sehr praktisch ist?

Hi @stevenschlansker - Ich komme aus der Perspektive von "developers first experience". Der obige Code stammt aus Ihrem eigenen v2-Tutorial, das meiner Meinung nach bewundernswert minimalistisch ist. Und in der Tat würden Sie bei einer JVM-gehosteten Sprache wie Groovy, die eine Javascript-ähnliche Karte eingebaut hat, wahrscheinlich häufiger ein nicht typisiertes Ergebnis sehen.

@javajosh was hältst du von https://github.com/jdbi/jdbi/pull/925 ?

@stevenschlansker Meinten Sie #928 ?

@stevenschlansker Definitiv eine Verbesserung! Aber es ist immer noch ausführlicher als v2. :) Dies ist zusätzlich zu der größeren Ausführlichkeit in maven usw. Ich möchte nur nicht, dass JDBI den Weg von JUnit geht, das Schwierigkeiten hatte, die Leute dazu zu bringen, v4 zu übernehmen, weil es einige nette Funktionen hatte, aber weitaus komplizierter war als v3 und v3 war "gut genug". Ich habe das gleiche Gefühl bei der "withHandle"-Syntax (obwohl ich Ihren Instinkt verstehe, alle baumelnden Handles zu eliminieren).

@javajosh Sie haben immer noch Jdbi.open() , wenn Sie mehr Kontrolle wünschen, obwohl wir empfehlen, dass Sie es aus Sicherheitsgründen innerhalb eines Try-with-Ressourcen-Blocks verwenden.

Beginn der Arbeit an den Migrationsdokumenten von v2 zu v3.

@javajosh Um auf die Methode ResultBearing.list() zurückzukommen, die ein List<Map<String,Object>> zurückgibt: Ich bin mir nicht sicher, ob das Hinzufügen eine gute Idee war, besonders so spät im Veröffentlichungszyklus.

Ich verstehe Ihre Bedenken hinsichtlich der Ausführlichkeit, aber diese Ausführlichkeit dient dazu, die Absicht des Entwicklers zu verdeutlichen:

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

ist für den Leser klarer als:

handle.createQuery(sql)
    .list()

Es ist eine heikle Sache, und ich beneide Sie nicht darum, dass Sie sich entscheiden müssen. JDBI ist eine nette Bibliothek, und ich bin froh, dass ich einfach meine Bedenken bezüglich der Ausführlichkeit angemeldet habe; Ob es in diesem speziellen Fall sinnvoll ist, eine Convenience-Methode hinzuzufügen, bin ich mir nicht sicher und würde eher Ihrem Urteil vertrauen als meinem, da ich nicht ernsthaft an dem Projekt beteiligt bin! Danke fürs Zuhören!

Bitte lassen Sie uns wissen, wenn Sie ein konkretes Beispiel dafür haben, wie es mit einem kürzeren Namen besser ist, oder ein Beispiel dafür, wie wir ihn verbessern könnten 😄