Jdbi: 개발자 가이드: v2에서 v3으로 마이그레이션

소규모 프로젝트 이전 시 참고 사항:

이름이 변경된 클래스(가져오기를 삭제하고 IDE에서 수정하도록 하는 것만큼 간단하지 않음):

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

Jdbi 의 생성자는 create() 팩토리 메소드로 대체되었습니다.

ResultSetMapper 는 RowMapper map 메서드에는 더 이상 행 인덱스가 없습니다. ResultSetMapper 라는 클래스가 Jdbi 3에 존재하지만 다른 용도로 사용됩니다. @Mapper 는 @UseRowMapper 로 바뀝니다. $#$ Jdbi 의 registerMapper() 는 registerRowMapper() 로 바뀝니다.

@BindIn 는 @BindList 로 대체되었으며 더 이상 StringTemplate이 필요하지 않습니다.

기본 Jdbi 템플릿을 사용하면 꺾쇠 괄호가 인용되지 않습니다. 즉, 도구 -> 데이터베이스 -> 사용자 패턴 아래에서 매개변수 패턴을 구성한 후 IntelliJ가 구문을 이해합니다.

Query 에는 더 이상 Map 의 기본 유형이 없으므로 list() 를 직접 호출할 수 없습니다. $ list() $ 을 호출하기 전에 mapToMap() 에 전화하십시오.

TransactionStatus 는 더 이상 존재하지 않습니다.

TransactionConsumer.useTransaction() 는 이제 Handle 사용하므로 Jdbi 또는 Jdbi에서 useTransaction() 메서드를 사용할 때 TransactionStatus 인수를 제거해야 합니다 Handle .

TransactionCallback.inTransaction() 는 이제 Handle TransactionStatus 하므로 inTransaction() Jdbi 또는 Handle .

CallbackFailedException 는 더 이상 존재하지 않습니다. HandleConsumer , HandleCallback , TransactionalConsumer 및 TransactionalCallback 와 같은 다양한 기능 인터페이스는 이제 모든 예외 유형을 throw할 수 있습니다(그러나 불필요한 검사를 피하기 위해 제네릭 사용이 제한됨 예외 처리).

SQL 개체 지원은 기본적으로 더 이상 사용할 수 없습니다. 생성된 Jdbi 인스턴스마다 등록해야 합니다.

IntelliJ의 Migrate Refactor는 마이그레이션을 시작하는 데 도움이 되었습니다.

함께 만들어주신 @electrum 에게 감사드립니다! 이것은 큰 도움이 될 것입니다

내 프레젠테이션 검토에서 몇 가지 추가 참고 사항:

• org.jdbi:jdbi -> org로 이름이 변경된 아티팩트. jdbi:jdbi3 , :jdbi3-sqlobject, :jdbi3-guava 등
• 코어 패키지 변경: org.skife.jdbi.v2 -> org.jdbi.v3. 즉, 마이그레이션하는 동안 v2와 v3이 프로젝트에 공존할 수 있습니다.
• 이름 변경: GetHandle -> SqlObject
• v3 인수 및 매퍼 팩토리는 java.lang.reflect.Type 를 사용하는 반면 v2 는 java.lang.Class 를 사용합니다. 이는 v3가 v2가 처리할 수 없는 복잡한 일반 유형 서명을 처리할 수 있음을 의미합니다.
• v3 인수 및 매퍼 팩토리 및 선택 사항을 반환하는 단일 메서드 기능 인터페이스. v2에는 별도의 accept() 및 build() 메서드가 있습니다.
• v3의 SQL 개체 유형은 클래스가 아닌 공용 인터페이스여야 합니다. 메서드 반환 형식도 마찬가지로 public이어야 합니다. 이는 SQL 개체 구현이 CGLIB에서 인터페이스만 지원하는 java.lang.reflect.Proxy로 전환하기 때문입니다.
• $# -parameters 플래그가 활성화된 상태에서 코드를 컴파일하여 SQL Object 메서드 매개변수의 @Bind 주석을 선택 사항으로 만들 수 있습니다.
• 주문형 SQL 개체는 Iterables를 반환하는 메서드에서 제대로 작동하지 않습니다. 주문형 개체는 각 메서드 호출 후에 핸들을 엄격하게 닫고 v2에서와 같이 반복 가능한 사용을 완료하기 위해 더 이상 "문을 열어 두지" 않습니다. 이것은 연결 누출의 주요 원인을 차단합니다.
• SQL 개체는 더 이상 닫을 수 없습니다. 즉, 주문형이거나 해당 수명 주기가 연결된 핸들의 수명 주기와 연결되어 있습니다.
• StatementLocator 인터페이스가 코어에서 제거되었습니다. 모든 핵심 명령문은 이제 실제 SQL을 수신할 것으로 예상합니다. 비슷한 개념인 SqlLocator 가 추가되었지만 SQL Objects 영역에서만 추가되었습니다.

다른 하나: StatementRewriter 가 TemplateEngine 및 SqlParser 로 리팩토링되었습니다.

목록에 추가하는 데 매우 중요한 것은 선택 동작입니다. 그것은 이것에서 갔다 :

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

이에:

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

v3의 추가 기능과 유연성, 안전성이 장황한 대가를 치르지 않았으면 합니다.

@javajosh 님 , 우리는 Map 개체에 대한 매핑을 억제하려고 하기 때문에 특정 항목이 너무 나쁘다고 생각하지 않았습니다. 다른 것이 아니라면 키의 대소문자 구분 규칙이 혼란스럽습니다. 정의된 유형을 직접 생성하는 대신 Map 를 내보내야 하는 이유가 있습니까? 나는 개인적으로 항상 작은 결과 클래스(생성자/필드/속성 매퍼 및 바인더 사용)를 작성하고 항상 Map 사용을 피합니다. 매우 편리한 사용 사례가 있습니까?

안녕하세요 @stevenschlansker - 저는 "개발자 첫 경험"의 관점에서 접근하고 있습니다. 위의 코드는 당신 자신의 v2 튜토리얼에서 가져온 것입니다. 그리고 실제로 자바스크립트와 같은 맵이 내장된 Groovy와 같은 JVM 호스팅 언어를 사용하면 유형이 지정되지 않은 결과를 더 자주 볼 수 있습니다.

@javajosh https://github.com/jdbi/jdbi/pull/925 에 대해 어떻게 생각하세요?

@stevenschlansker #928을 의미합니까?

@stevenschlansker 확실히 개선되었습니다! 그러나 v2보다 여전히 더 장황합니다. :) 이것은 maven 등에서의 더 큰 장황함에 추가됩니다. JDBI가 몇 가지 멋진 기능을 가지고 있기 때문에 사람들이 v4를 채택하도록 고군분투한 JUnit의 방식으로 가는 것을 보고 싶지 않습니다. v3와 v3는 "충분히 좋았습니다". 나는 "withHandle" 구문에 대해 같은 느낌을 가지고 있습니다(모든 매달린 핸들을 제거하려는 본능을 이해하지만).

@javajosh 더 강력한 제어를 원하면 여전히 Jdbi.open() 가 있지만 안전을 위해 try-with-resources 블록 내에서 사용하는 것이 좋습니다.

v2에서 v3로의 마이그레이션 문서 작업을 시작합니다.

@javajosh $# List<Map<String,Object>> ResultBearing.list() 메서드로 돌아갑니다. 특히 릴리스 주기 후반에 이것을 추가하는 것이 좋은 생각인지 잘 모르겠습니다.

자세한 내용에 대한 귀하의 우려에 공감하지만, 그 자세한 내용은 개발자 의도를 명확히 하는 데 도움이 됩니다.

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

다음보다 독자에게 더 명확합니다.

handle.createQuery(sql)
    .list()

그것은 민감한 일이며, 나는 당신이 선택해야 하는 위치가 부럽지 않습니다. JDBI는 훌륭한 라이브러리이며, 장황함에 대한 우려 사항을 등록하게 되어 기쁩니다. 이 특별한 경우에 편리한 방법을 추가하는 것이 의미가 있는지 여부는 확실하지 않으며 프로젝트에 진지하게 관여하지 않기 때문에 내 판단을 신뢰하는 경향이 있습니다! 듣기 주셔서 감사합니다!

더 짧은 이름을 사용하는 것이 더 나은 방법에 대한 구체적인 예나 개선할 수 있는 방법에 대한 쇼케이스가 있으면 알려주세요 😄