Jdbi: Guía del desarrollador: migración de v2 a v3

Notas de la migración de un proyecto pequeño:

Clases renombradas (por lo que no es tan simple como eliminar las importaciones y dejar que el IDE lo arregle):

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

Los constructores de Jdbi han sido reemplazados por un método de fábrica create() .

ResultSetMapper se reemplaza por RowMapper y el método map ya no tiene el índice de fila. Existe una clase llamada ResultSetMapper en Jdbi 3, pero tiene un propósito diferente. @Mapper se reemplaza por @UseRowMapper . registerMapper() en Jdbi se reemplaza con registerRowMapper() .

@BindIn se reemplaza por @BindList y ya no requiere StringTemplate.

Con la plantilla Jdbi predeterminada, los corchetes angulares no se citan, lo que significa que IntelliJ comprende la sintaxis después de configurar el patrón de parámetros en Herramientas -> Base de datos -> Patrones de usuario .

Query ya no tiene un tipo predeterminado de Map y, por lo tanto, no se puede llamar directamente a list() . Llame a mapToMap() antes de llamar a list() .

TransactionStatus ya no existe.

TransactionConsumer.useTransaction() solo toma un Handle ahora, por lo que el argumento TransactionStatus debe eliminarse cuando se usa con los métodos useTransaction() en Jdbi o Handle .

TransactionCallback.inTransaction() solo toma un Handle ahora, por lo que el argumento TransactionStatus debe eliminarse cuando se usa con los métodos inTransaction() en Jdbi o Handle .

CallbackFailedException ya no existe. Las diversas interfaces funcionales, como HandleConsumer , HandleCallback , TransactionalConsumer y TransactionalCallback , ahora pueden lanzar cualquier tipo de excepción (pero se restringen al usar genéricos para evitar controles innecesarios). manejo de excepciones).

La compatibilidad con SQL Object ya no está disponible de forma predeterminada. Se debe registrar cada Jdbi instancia creada.

Migrate Refactor de IntelliJ fue útil para iniciar la migración.

¡Gracias @electrum por armar esto! esto sera de gran ayuda

Algunas notas adicionales de la revisión de mi presentación:

• Artefactos renombrados org.jdbi:jdbi -> org. jdbi:jdbi3 ,:jdbi3-sqlobject,:jdbi3-guayaba, etc.
• Paquete principal cambiado: org.skife.jdbi.v2 -> org.jdbi.v3. Esto significa que v2 y v3 pueden coexistir en un proyecto mientras realiza la migración
• Renombrado: GetHandle -> SqlObject
• Las fábricas de argumentos y mapeadores v3 usan java.lang.reflect.Type , mientras que v2 usaba java.lang.Class . Esto significa que v3 es capaz de manejar firmas de tipo genérico complejas que v2 no pudo.
• Fábricas de mapeadores y argumentos v3 e interfaces funcionales de método único que devuelven un opcional. v2 tenía métodos accepts() y build() separados.
• Los tipos de objetos SQL en v3 solo deben ser interfaces públicas, no clases. Los tipos de retorno de método también deben ser públicos. Esto se debe a que la implementación de SQL Object cambia de CGLIB a java.lang.reflect.Proxy, que solo admite interfaces.
• Las anotaciones @Bind en los parámetros del método SQL Object se pueden hacer opcionales al compilar su código con el indicador -parameters habilitado.
• Los objetos SQL bajo demanda no funcionan bien con los métodos que devuelven Iterables. Los objetos bajo demanda cierran estrictamente el identificador después de cada llamada de método y ya no "mantienen la puerta abierta" para que termine de consumir el iterable como lo hicieron en v2. Esto excluye una fuente importante de fugas de conexión.
• Los objetos SQL ya no se pueden cerrar: están bajo demanda o su ciclo de vida está vinculado al ciclo de vida del identificador al que se adjuntaron.
• La interfaz StatementLocator se elimina del núcleo. Todas las declaraciones principales esperan recibir el SQL real ahora. Se agregó un concepto similar, SqlLocator , pero solo en el ámbito de los objetos SQL.

Otro: StatementRewriter se ha refactorizado en TemplateEngine y SqlParser .

Muy importante para agregar a la lista es el comportamiento de selección. Pasó de esto:

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

A esto:

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

Desearía que la potencia, la flexibilidad y la seguridad adicionales de v3 no vinieran con el precio de la verbosidad.

Hola @javajosh , no consideramos que ese en particular sea tan malo porque estamos tratando de desalentar el mapeo a objetos Map . Por lo menos, las reglas sobre la distinción entre mayúsculas y minúsculas para las claves son confusas. ¿Hay alguna razón por la que deba emitir un Map en lugar de crear su propio tipo definido? Personalmente, siempre escribiré pequeñas clases de resultados (usando constructores / campos / mapeadores y carpetas de propiedades) y siempre evitaré usar Map . ¿Tiene algún caso de uso en el que sea muy conveniente?

Hola, @stevenschlansker : lo entiendo desde la perspectiva de la "primera experiencia de los desarrolladores". El código anterior está tomado de su propio tutorial v2, que creo que es admirablemente minimalista. Y, de hecho, con un lenguaje alojado en JVM como Groovy, que tiene un mapa incorporado similar a javascript, probablemente verá un resultado sin tipo con más frecuencia.

@javajosh , ¿qué piensas de https://github.com/jdbi/jdbi/pull/925 ?

@stevenschlansker ¿Quiso decir #928?

@stevenschlansker ¡ Definitivamente una mejora! Pero aún es más detallado que v2. :) Esto se suma a la mayor verbosidad en maven, etc. Simplemente no quiero ver a JDBI seguir el camino de JUnit, que luchó para que la gente adoptara v4 porque tenía algunas características interesantes, pero era mucho más complicado que v3 y v3 eran "suficientemente buenos". Tengo la misma sensación sobre la sintaxis "withHandle" (aunque entiendo su instinto de eliminar todos los identificadores colgantes).

@javajosh Todavía tiene Jdbi.open() si desea un mayor control, aunque le recomendamos que lo use dentro de un bloque de prueba con recursos por seguridad.

Comenzando a trabajar en los documentos de migración v2 a v3.

@javajosh Volviendo al método ResultBearing.list() que devuelve un List<Map<String,Object>> : no estoy seguro de que agregar esto fuera una buena idea, especialmente a estas alturas del ciclo de lanzamiento.

Soy empático con sus preocupaciones sobre la verbosidad, pero esa verbosidad sirve para aclarar la intención del desarrollador:

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

es más claro para el lector que:

handle.createQuery(sql)
    .list()

Es una cosa delicada, y no envidio tu posición al tener que elegir. JDBI es una buena biblioteca, y me alegro de haber registrado simplemente mis preocupaciones sobre la verbosidad; si tiene sentido agregar un método de conveniencia en este caso específico, no estoy seguro y tendería a confiar en su juicio sobre el mío, ¡ya que no estoy seriamente involucrado en el proyecto! ¡Gracias por su atención!

Háganos saber si se le ocurre un ejemplo concreto de cómo es mejor con un nombre más corto o una demostración de cómo podríamos mejorarlo 😄