Jdbi: ZonedDateTime용 내장 매퍼는 시간대 정보를 버립니다.

당신이 옳았지만 이것이 현재 JDBC가 지원하는 전부입니다. 모든 java.time 유형을 시간대/오프셋 데이터가 없는 java.util 또는 java.sql 유형으로 변환해야 합니다.

호기심에 Postgres를 사용하고 있습니까? TIMESTAMP WITH TIME ZONE이 예상과 다르게 작동하기 때문입니다.

Postgres를 사용하고 있습니까? TIMESTAMP WITH TIME ZONE이 예상과 다르게 작동하기 때문입니다.

나는 알고있다. (그렇지 않으면 매우 표준을 준수하는 데이터베이스 btw에 대한 큰 실망입니다.)

당신이 옳았지만 이것이 현재 JDBC가 지원하는 전부입니다.

JDBI가 H2의 org.h2.api.TimestampWithTimeZone 를 수동으로 수행할 필요 없이 _어떤 방식으로_ 가져오기를 기대했습니다.
TIMESTAMP W/TZ 값을 가져오는 "휴대용"(다른 드라이버에서 작동) 방법을 모르기 때문에 진정한 솔루션이 없습니다.
그러나 모든 정보를 가져오지 않는다면 그렇게 하는 척 해서는 안 됩니다. 즉, IMO에는 ZonedDateTime 대한 내장 매퍼가 없어야 합니다. 그렇지 않으면 Postgres처럼 하고 있습니다. 내가 기대한 것과는 다릅니다.

사용자가 ZonedDateTime 를 사용하고 데이터베이스의 시간대 대신 앱 서버의 시간대에서 반환되는 것을 신경 쓰지 않는다면 여전히 편리하다고 생각합니다.

그건 그렇고, Dropwizard는 사용자가 명시적으로 데이터베이스의 시간대를 설정할 수 있는 JDBI2용 다른 버전의 매퍼를 사용합니다. https://github.com/dropwizard/dropwizard/blob/master/dropwizard-jdbi/src/main/java /io/dropwizard/jdbi/args/ZonedDateTimeMapper.java

H2로 ZonedDateTime 를 가져오거나 설정하는 방법에 대한 예제 코드를 제공할 수 있다면 기꺼이 플러그인에 추가하겠습니다.

사용자가 ZonedDateTime을 사용하고 데이터베이스의 시간대 대신 앱 서버의 시간대에서 반환되는 것을 신경 쓰지 않는다면 여전히 편리하다고 생각합니다.

@arteam , 사용자가 이러한 선택을 하는 것을 알고 있다면 동의합니다.

그러나 AFAIR https://github.com/jdbi/jdbi/blob/master/core/src/main/java/org/jdbi/v3/core/mapper/BuiltInMapperFactory.java#L182 는 H2에서도 작동하지 않습니다. TS w TZ, rs.getTimestamp(..) 는 해당 유형에 대해 지원되지 않습니다.

H2로 ZonedDateTime을 가져오거나 설정하는 방법에 대한 예제 코드를 제공할 수 있다면 기꺼이 플러그인에 추가하겠습니다.

나는 이식 가능한 방법을 모릅니다. 내가 아는 유일한 방법은 (org.h2.api.TimestampWithTimeZone) rs.getObject(..) 이고 예를 들어 Oracle의 경우 비슷하지만 Oracle 전용 클래스가 있습니다.

일반적으로 API에 의해 _강제_되어 올바른 변환( LocalDateTime 타임스탬프)을 사용하고 명시적으로 "zone-ing"을 추가하는 것을 선호합니다.

당신은 동의하지 않는 것 같습니다. 즉, 이 문제를 계속 열어둘 필요가 없습니다.

우리가 스택에서 수행하는 한 가지는 실제로 Java의 시간대 == Postgres의 시간대라고 주장하며, 이 경우 모든 것이 올바르게 작동합니다. 불일치가 있는 경우 경고를 표시해야 합니까? 사람들이 기대하는 기능을 활성화하는 것과 TZ를 준수하는 것 사이에서 괜찮은 타협이 될까요?

왜 그렇게 빨리 닫았는지 모르겠지만, 더 논의할 것이 있다고 느꼈습니다.

모든 공급업체에 대해 이 문제를 일반적으로 해결할 수는 없더라도 공급업체별로 이를 확실히 지원할 수 있습니다.

Jdbi와 함께 제공되는 매퍼 및 인수 팩토리는 다른 매퍼/인수를 등록하여 간단히 재정의할 수 있습니다. 마지막 등록(유형별)이 우선합니다.

PostgresPlugin 에 대한 소스를 보면 LocalDate , LocalTime 대해 LocalDate ResultSet.getObject(Class) 를 사용하여 대체 매퍼를 제공하는 JavaTimeMapperFactory 를 등록하는 것을 볼 수 있습니다. LocalTime , LocalDateTime 및 OffsetDateTime , Postgres JDBC 드라이버에서 직접 지원합니다.

H2에 영역을 생략하지 않고 ZonedDateTime 를 저장할 수 있는 방법이 있으면 H2DatabasePlugin 를 수정하여 사용자 지정 매퍼를 사용할 수 있습니다.

지금은 이것을 다시 열겠습니다. 여기에 좋은 토론이 있습니다. @findepi 우리는 일을 올바르게 하는 데 많은 관심을 가지고 있습니다! 우리는 또한 실용적이고 사람들은 실제로 시간 유형을 사용할 수 있기를 기대합니다...

이 대화에서 jdbi 팀이 예를 들어 hsqldb에 대한 인수와 매퍼를 제공하는 jdbi3-hsqldb subproject/artifact/...를 갖는 데 관심이 있다는 것을 올바르게 이해하고 있습니까? 변환)?

전적으로.

솔직히 말해서 나는 jdbi가 지속되지 않는 시간대/오프셋과 같이 실제로 정확하게 매핑될 수 없는 것에 대한 매퍼를 제공해서는 안 된다고 말한 @findepi에 동의합니다... 여기에서 "타협"이라는 아이디어는 매우 위험하게 들립니다. 저에게 - 저는 항상 전체 데이터 무결성을 모든 프로젝트에서 가장 높은 우선 순위 중 하나로 간주해 왔습니다. 사용자는 라이브러리가 올바르게 작동하는지 다시 확인할 필요가 없습니다.

jdbi에서 제공하는 매퍼가 몰래 변경되었을 때를 아는 것보다 jdbi가 주어진 유형에 대한 매퍼를 제공하지 않는다는 것을 테스트 실행 중에 런타임 예외로 알아낸 다음 직접 작성하고 싶습니다. 내 데이터.

db 자체(hsqldb)와 jdbi 모두에서 구현 정확성/데이터 무결성을 확인하기 위해 여러 유형의 값을 쓰고 읽는 대규모 단위 테스트가 있으므로 모든 문제를 처리하기 위해 jdbi 매퍼/인수를 작성할 수 있습니다. 나는 hsqldb가 현재 기본적으로 그렇게 말하는 사양에도 불구하고 java.time을 지원하지 않기 때문에(거대한 버그) 몇 가지를 작성해야 했습니다. 나는 아직 내 시스템이 아닌 다른 영역/오프셋으로 java.time 객체를 테스트할 생각을 하지 않았기 때문에 그냥 했고, 충분히 확실히, 그것들은 모두 시스템 값으로 리셋된 오프셋/영역으로 돌아오지만 jdbi의 매핑으로 인해 hsqldb 버그 때문이 아니라 Timestamp로.

결함이 있는 매퍼를 jdbi3에서 제거하고 해당 구현이 완전히 수정될 수 있는 공급업체별 아티팩트(jdbi3-hsqldb 및 기타)로 이동하는 것이 좋습니다.

어쨌든 이미 내 자신의 프로젝트에 필요한 모든 매퍼와 인수를 작성했기 때문에 jdbi-hsqldb를 직접 기여할 수 있습니다.

나는 아마도 더 현명한 길이었을 것이라는 데 동의하지만 이 시점에서 v3가 출시되고 고양이는 가방에서 벗어났습니다.

이러한 매퍼 또는 인수 팩토리를 제거하면 이에 의존하는 기존 사용자가 크게 변경됩니다.

누군가가 이미 그들에게 의존하고 있다면(결함을 알고 있든 없든) 해당 사용자가 다시 패치하는 것이 충분히 간단할 것이라고 생각합니다. 변환은 거의 한 줄짜리입니다. 반면에 그것들을 유지하는 것은 그것이 제공되기 때문에 작동한다고 가정하는 나와 같은 점점 더 많은 사람들로 이어질 것이며(솔직히, 누가 jdbc의 표준 시간대 지원과 같은 모든 기술 사양을 마음으로 알고 있습니까?) 그럴 수도 있고 아닐 수도 있습니다. 나중에 그들의 데이터가 잘못 처리되었다는 것을 알게 됩니다...
기본적으로 나는 그것들을 그대로 두어서 잠재적인 미래의 피해가 그것들을 제거하여 업데이트한 소수에게 지금 입힌 피해보다 훨씬 더 크다고 생각합니다.

@TheRealMarnes 제 생각에 기능을 제거하는 것은 (우리가 그것이 존재하지 않아야 한다는 데 동의하더라도) 그렇게 간단하지 않다고 생각합니다. 사람들은 의미론적 버전 관리를 가정하는 경향이 있습니다(프로젝트가 이를 따르든 따르지 않든). 프로젝트 규칙을 모르지만 일반적으로 v3에서 더 이상 사용하지 않을 것입니다(사용되지 않는 것으로 표시할 수 있는 API 메서드가 없고 문서 및 로깅이 남아 있기 때문에 여기서 사용 중단은 까다롭습니다). v4에서 기능을 제거합니다. , 사람들이 릴리스 정보/마이그레이션 가이드를 읽을 것으로 기대합니다.

나는 그런 일이 결코 간단하지 않고 해결책이 항상 누군가를 불행하게 만들 것이라는 데 동의하지만, 나는 목적이 수단을 정당화하고 결함이 있는 시스템을 더 나은 시스템으로 교체하는 것은 장기적으로 항상 화를 낼 가치가 있다고 생각하는 경향이 있습니다. 그리고 사람들이 릴리스 노트/마이그레이션 가이드를 읽을 것이라고 기대하는 것은 비합리적이라고 생각하지 않습니다... 유지 관리 및 마이너 업데이트는 물론이지만 주요 업데이트는 아닙니다. Jdbi3 자체는 새로운 가이드를 읽지 않고는 jdbi2에서 오는 것을 사용할 수 없습니다.

나는 그 매퍼/인수를 비활성화하는 솔루션을 뒤에서 얻을 수 있다고 생각합니다. 단 한 줄짜리로 복원하면 해당 매퍼를 플러그인으로 옮길 수 있습니까?

공급업체에 한정되지 않은 jdbi3-core-experimental ?
편집: 내 나쁜, 당신은 jdbi.installPlugin(new ExperimentalMappersPlugin())

이것이 실제로 '실험적'인 것은 아니지만 아이디어가 될 것입니다.

TimezoneInsensitiveJavaTimeMappers 다음 :P

매퍼뿐만 아니라 인수 팩토리이기도 합니다.

JavaTimeYoloTZPlugin 어때요?:윙크:

모든 공급업체에 대해 이 문제를 일반적으로 해결할 수는 없더라도 공급업체별로 이를 확실히 지원할 수 있습니다.

@qualidafial 저는 최근에 Java8 이후 세계에서 날짜/시간 값을 검색하기 위한 사실상의 표준이 부상하고 있는 것 같다는 것을 배웠습니다.

먼저 배경이 조금 더 있습니다.

• JDBI의 TIMESTAMP WITH TIME ZONE ZonedDateTime 로의 변환에 대해 이 문제를 만들었습니다. 이는 시간대 정보를 삭제합니다.
• 모든 JDBC API에는 또 다른 문제가 있습니다. 이것이 TIMESTAMP , DATE , TIME 객체가 검색되는 방식입니다. 즉, java.sql.{Timestamp,Date,Time} 클래스를 사용합니다. 클래스는 모두 java.util.Date 에서 확장됩니다. Calendar 가 어떻게 도입되었고 java.util.Date 의 메소드가 년/월/일/시/분/초를 처리하는지 기억하는 사람이 있습니까? 그럴만한 이유가 있습니다( Calendar 가 모든 문제를 해결했다는 의미는 아닙니다).
  
  
  
  • _JVM 시간대_가 현지 시간을 준수하지 않으면 데이터베이스에서 java.sql.Timestamp 를 검색할 수 없습니다. 따라서 미국에서 실행되는 앱은 일부 공유 데이터베이스에 2017-03-26 02:30:00 의 타임스탬프 값(영역 없이!)을 저장할 수 있지만 유럽에서 실행되는 앱(예: Europe/Berlin 을 JVM 영역으로 사용)은 저장하지 않습니다. 당시 유럽에는 DST가 있었기 때문에 이 타임스탬프를 검색할 수 있습니다.
  
  
  • 오, 이것은 거의 동일한 클래스이기 때문에 java.sql.Date 에도 동일하게 적용됩니다. java.sql.Date 는 자정에 java.sql.Timestamp 것처럼 날짜를 나타내지만 자정이 없는 경우도 있습니다. 자정에 DST가 변경되는 구역이 있습니다(현재 또는 과거).
  
  
  • java.sql.Time 는 검색된 시간을 1970-01-01의 타임스탬프로 나타내기 때문에 이 문제가 없다고 생각하십니까? 불행히도 해당 날짜에 정책이 변경될 만큼 충분히 좋은 영역이 있기 때문에(예: America/Bahia_Banderas , America/Hermosillo ). JVM이 이러한 영역인 경우 JDBC를 사용하는 프로그램은 특정 TIME 값을 검색할 수 없습니다.
  
  

해결책 은 JDBC 이전 API를 사용하여 검색하고 이를 새 클래스로 변환하는 것입니다. 그러나 이것은 일반적으로 잘못되었습니다.

• ~ resultSet.getTimestamp(col).toLocalDateTime() ~
• ~ resultSet.getDate(col).toLocalDate() ~
• ~ resultSet.getTime(col).toLocalTime() ~

이것은 위에서 설명한 문제를 해결하지 못한다는 점을 제외하고는 잘 컴파일되고 작동합니다(JVM 영역이 Pacific/Apia 이고 검색된 날짜가 2011-12-30 인 경우 날짜 검색도 작동하지 않음 ;)

이제 떠오르는 솔루션으로. ResultSet 에는 JDBC 드라이버에 유형을 변환하도록 요청할 수 있는 덜 인기 있는 API가 있습니다.

• resultSet.getObject(col, LocalDateTime.class) // for TIMESTAMP
• resultSet.getObject(col, LocalDate.class) // for DATE
• resultSet.getObject(col, LocalTime.class) // for TIME
• resultSet.getObject(col, ZonedDateTime.class) // for TIMESTAMP WITH TIME ZONE

이것은 PostgreSQL, MySQL, Oracle 및 H2용 JDBC 드라이버와 함께 작동하는 것으로 보입니다. 그리고 마술은 위에서 설명한 "JVM 영역의 표현 불가능성" 문제를 우회합니다.
이 변환이 예를 들어 SQL Server 드라이버에서 아직 구현되지는 않았지만 이것이 JDBI가 제공하는 Java 시간 클래스에 대한 기본 매핑이 될 수 있다고 생각합니다.

메모:
JDBC 4.2 사양은 드라이버가 이것을 구현해야 한다고 요구하지 않습니다. 그러나 사양에서는 PreparedStatement.setObject 및 RowSet.setObject 가 Java Time 클래스의 인스턴스를 수락하고 올바르게 처리해야 하므로 드라이버는 어쨌든 이러한 클래스를 명시적으로 지원해야 합니다.

멋지다! 내 주요 관심사는 이 접근 방식으로 변경하면 난해한 드라이버를 사용하는 사용자에게 퇴행으로 나타날 수 있다는 것입니다. 그러나 릴리스 노트에 적절한 메시지를 전달하면 올바른 방식으로 일을 한다는 명목으로 기술적으로 이 작은 변화를 만들 수 있습니다...

@stevenschlansker 당신이 맞습니다. JDBI가 제공할 수 있다고 생각합니다.

• 사용자가 원래 동작을 복원하기 위해 연결할 수 있는 선택적 매핑 집합
• 릴리스 노트의 적절한 설명(또는 주요 버전 범프)

부 버전으로 유지합시다, 우리는 방금 3을 릴리스했습니다. 이것은 잘못 유지하면 브레이킹 체인지일 뿐입니다... ;)

내가 듣고있는 것처럼 들리는 것을 재생하려면 :

• 기존 내장 java.time 매퍼를 별도의 플러그인으로 이동합니다( YoloTimePlugin 좋아요).
• java.sql 유형에서 변환하는 대신 ResultSet.getObject(column, type) 를 사용하는 새 내장 매퍼를 대신 추가합니다.
• 릴리스 정보에서 이 주요 변경 사항을 문서화합니다. 이 변경 사항의 영향과 영향을 받는 데이터베이스 공급업체, 문제를 완화하기 위해 사용자가 해야 할 일에 대해 설명합니다.

이 뒤에 갈 수 있습니다.

우리는 여전히 이러한 날짜/시간 개체를 바인딩하는 것에 대한 질문에 대답하지 않았습니다. 데이터베이스 외부의 매핑 결과에 대해 변경하는 모든 것은 날짜/시간 인수를 SQL 문에 바인딩하는 방식으로 미러링되어야 합니다.

데이터베이스에서 결과를 매핑하는 것과 관련하여 변경한 모든 사항은 날짜/시간 인수를 SQL 문에 바인딩하는 방식으로 미러링되어야 합니다.
@qualidafial , 아주 좋은 질문입니다. 나는 이것을 테스트하지 않았다. 이것은 JDBC 4.2 사양에서 명시적으로 다루고 있으므로 _작동해야 합니다™_.

이것은 JDBC 4.2 사양에서 명시적으로 다루고 있으므로 _작동해야 합니다™_.

이것은 JDBC 드라이버 구현자가 사양을 완벽하게 따른다고 가정합니다. 버그가 없는 JDBC 드라이버 구현을 아직 찾지 못했습니다.

모든 데이터베이스에 대해 매퍼를 플러그인에 제공하고 데이터 유형에 대한 지원이 다른 다양한 버전을 제공하는 것은 너무 성가신 일이라는 생각이 듭니다. 아마도 더 빈 슬레이트 접근 방식이 작동할 수 있습니다. 미리 설치된 매퍼가 없는 Jdbi 인스턴스로 시작하고 핵심 아티팩트는 수동으로 선택하여 설치할 수 있는 여러 매퍼를 제공하며 일부는 동일한 데이터 유형을 처리하기 위해 다른 논리를 갖습니다 - get/ setObject, get/setX, 다른 유형으로의 변환 등. 데이터베이스(버전) 및 응용 프로그램 논리에 가장 적합한 매퍼를 스스로 파악하고 단위 테스트를 사용하여 확인해야 합니다.

그것이 기본적으로 내가 이미 내 프로젝트에서 이미 하고 있는 일입니다. 내 db에서 작동하지 않는 Jdbi에 사전 설치된 일부 매퍼가 있으며 지금은 필요하지 않으므로 UnsupportedOperationException을 던지는 인수/매퍼 팩토리로 실제로 재정의했습니다. 구현(아래 참조).

이것은 모든 것이 절대적으로 작동하는지 확인하기 위해 자신의 db와 친밀해지고 싶어하는 사람들을 위한 솔루션이 될 것이며, Just Werk™에 물건을 원하는 사람들을 위해 (실제로 하는 한) 아무것도 변경하지 않을 것입니다.

• Jdbi 인스턴스에 메소드를 추가하여 모든 매퍼/인수를 지우십시오(클린 슬레이트).
• 우리가 수동으로 설치할 수 있도록 현재 내장 매퍼/인수 impl을 노출합니다.
• 수요가 증가할 때 핵심 아티팩트에 대체 매퍼 impls를 계속 추가하고 사람들이 스스로 설치하도록 하여 아래와 같이 가능한 모든 것을 생성합니다.

이렇게 함으로써 나는 hsqldb 드라이버에서 너무 많은 지점을 찾았습니다. hsqldb 드라이버에서 자체 사양(소스에 보고되고 수정되었지만 여전히 업데이트된 아티팩트를 게시하기를 여전히 기다리고 있음)에서 벗어나고 작업했습니다. 작동하는 매핑 논리를 직접 찾아 이러한 결함을 해결합니다.

// I want strings handled differently
<strong i="13">@Component</strong>
public class CleanStringArgumentFactory extends AbstractArgumentFactory<String> {
    protected CleanStringArgumentFactory() {
        super(Types.VARCHAR);
    }

    <strong i="14">@Override</strong>
    protected Argument build(String value, ConfigRegistry config) {
        return (position, statement, ctx) -> statement.setString(position, StringUtils.trimToNull(value));
    }
}

// no need for jdbi's built-in logic
<strong i="17">@Component</strong>
public class SetObjectArgumentFactory implements ArgumentFactory {
    private static final Set<Type> SUPPORTED = ImmutableSet.of(UUID.class, LocalDateTime.class);

    <strong i="18">@Override</strong>
    public Optional<Argument> build(Type type, Object value, ConfigRegistry config) {
        return SUPPORTED.contains(type)
            ? Optional.of(new LoggableArgument(value, (position, statement, context) -> statement.setObject(position, value)))
            : Optional.empty();
    }
}

// these built-ins don't work and I don't need them anyway
<strong i="21">@Component</strong>
public class UnsupportedArgumentFactory implements ArgumentFactory {
    private static final Set<Type> UNSUPPORTED = ImmutableSet.of(ZonedDateTime.class, OffsetDateTime.class, OffsetTime.class);

    <strong i="22">@Override</strong>
    public Optional<Argument> build(Type type, Object value, ConfigRegistry config) {
        if (UNSUPPORTED.contains(type)) {
            throw new UnsupportedOperationException(type.getTypeName() + " is not supported at the moment");
        } else {
            return Optional.empty();
        }
    }
}

// voodoo
<strong i="25">@Inject</strong>
    public JdbiConfiguration(
        @Named("dataSource") DataSource dataSource,
        Set<ArgumentFactory> arguments,
        Set<ColumnMapper> mappers,
        Set<ColumnMapperFactory> mapperFactories
    ) {
        jdbi = Jdbi.create(dataSource);
        jdbi.clearMappings();

        jdbi.installPlugin(new SqlObjectPlugin());

        arguments.forEach(jdbi::registerArgument);
        mapperFactories.forEach(jdbi::registerColumnMapper);
        mappers.forEach(jdbi::registerColumnMapper);

        // ...

        // Jdbi instance fine-tuned for my exact database and demands, without surprises and at my own responsibility

하부다? 예를 들어 활성화해야 하는 클래스 집합으로 초기화해야 하는 SetObjectArgumentFactory와 많은 데이터 유형에 대한 매핑 논리의 모든 종류의 변형을 제공할 수 있으며 적용 가능한 경우 몇 가지 구성 가능한 동작을 제공할 수 있습니다. 모두들 행복하세요. 최종 사용자로부터 약간의 작업이 필요하지만 jdbi가 내가 원하는 작업과 데이터베이스에서 지원하는 작업을 정확히 수행한다는 사실을 알게 되어 기분이 좋습니다.

모든 데이터베이스에 대해 매퍼를 플러그인에 제공하고 데이터 유형에 대한 지원이 다른 다양한 버전을 제공하는 것은 너무 성가신 일이라는 생각이 듭니다.

많은 데이터베이스 공급업체를 위한 플러그인을 갖고 싶습니다. 이리 와서 모두: 데이터베이스 벤더 또는 해당 JDBC 드라이버의 특성에 맞게 Jdbi를 조정하기 위해 데이터베이스에 몇 가지 사용자 정의가 필요하거나 원하는 경우 이에 대해 듣고 싶습니다. 또는 더 나은 아직, 우리는 pull 요청을 원합니다! :)

귀하의 데이터베이스가 TravisCI에서 직접 지원되는 경우 보너스 포인트로 실제로 이에 대한 테스트를 실행할 수 있습니다: https://docs.travis-ci.com/user/database-setup/

귀하의 "백지" 제안과 관련하여 저는 약간의 이의가 있습니다.

• 나는 아마도 둘 것 clearMappings() 직접의 방법을 RowMappers , ColumnMappers , Arguments 및 JdbiCollectors 대신에의 수업을 config (설정) Jdbi , 이름을 clear() 지정하겠습니다.
• 내장 매퍼, 인수 및 수집기를 공개하는 것이 약간 주저합니다. 그들 중 일부는 내부에 있기 때문에 우리가 무시하는 이상한 이름이나 디자인을 가지고 있습니다. API의 일부로 만들기 전에 일부를 리팩토링하고 싶을 것입니다.
• 백서가 정말 필요한지 궁금합니다. Jdbi의 모든 레지스트리 클래스는 last-registered-wins 접근 방식을 사용하므로 항상 즉시 사용 가능한 동작을 재정의할 수 있습니다. 그런 의미에서 백지 상태는 약간 과한 느낌입니다.

@jdbi/contributors 다른 사람이 관심을 가질만한 사람이 있습니까?

나는 당신이 선택한 것을 등록하는 것을 잊었을 경우를 대비하여 실수로 기본 매퍼를 사용하는 것을 피하기 위해 빈 슬레이트 아이디어를 포함시켰습니다. 기본 impl보다 NotImplementedException이 더 낫습니다. 최후의 승자는 훌륭하지만 원하지 않는 경우 무효화해야 하는 승패를 알 수 있는 방법이 없습니다.

가지고 있는 것이 아픈 것은 아닙니다. 사람들이 그 접근 방식을 원하지 않는다면 clear 메소드를 호출할 필요가 없으며 아무 것도 변경되지 않습니다. 기본값이 없는 작업 방식을 선호하는 사람들을 위한 것입니다.

기존 매퍼를 공개해서는 안 된다는 데 동의합니다. 깨끗한 슬레이트 옵션을 제공하기로 선택한 경우 매퍼와 바인더를 합리적인 Plugin 청크, PrimitivesPlugin , BoxedPrimitivesPlugin , CollectionsPlugin , 무엇이든 번들로 묶어야 합니다.

그런 다음 구성이 전혀 없는 "기본" jdbi에 대한 새 팩토리를 추가하고 이를 사용하도록 기존 팩토리를 수정하고 WholeJdbiEnchiladaPlugin 추가할 수 있습니다.

덧셈으로 빌드하기 어려운 경우를 보여줄 수 없다면 저는 'clear'에 대해 다소 반대합니다. 제게는 코드 냄새처럼 느껴집니다.

덧셈으로 빌드하기 어려운 경우를 보여줄 수 없다면 저는 'clear'에 대해 다소 반대합니다. 제게는 코드 냄새처럼 느껴집니다.

별도의 사전 구성이 없는 jdbi 팩토리를 추가하면 추가로 빌드하는 것이 어렵지 않으므로 실제로 clear()가 필요하지 않습니다.

맞습니다. 저는 여기에 동의한다고 생각합니다. 저는 clear() 스타일보다 새로운 "깨끗한" 팩토리 메소드를 추가하는 선호도를 표현한 것 뿐입니다.

그러면 모든 사람의 문제가 해결됩니까? 개인적으로 계획이 꽤 섹시하게 들린다고 생각합니다.

• Jdbi no-defaults로 설정(거의 모든 것에 예외를 던짐)
• 모든 기존 매퍼와 바인더(및 tx 핸들러 등)를 플러그인 번들 및 개별 클래스로 플러그인 가능( PrimitivesPlugin , BoxedPrimitivesPlugin 등)
• 몇 가지 대체 구현 제공( UTCJavaTimePlugin vs LocalJavaTimePlugin vs ConvertJavaTimeToUtilDatePlugin , GetObjectMapper.forClasses(Class... cs) , SetObjectArgumentFactory.forClasses(Class... cs) , NullsToDefaultsPrimitivesPlugin vs NullThrowsExceptionPrimitivesPlugin ) 및 동일한 방식으로(플러그인 및 개별적으로) 노출하여 사람들이 원하는 것을 정확히 취하여 원하는 전체 매핑 논리를 구성할 수 있습니다. 불법 null 또는 누락된 시간대 및 기타 가능한 불일치를 처리하기 위한 다양한 전략과 같이 여기에 잠재적으로 많은 매퍼 구성이 필요합니다.
• db 전용 번들 플러그인을 만들 수 있으므로 인기있는 데이터베이스 + 버전을 가진 사용자는 구성 없음 Jdbi 에서 시작하고 db ( HsqlDb2_4_0Plugin )에 대해 알려진 좋은 매핑 체계를 한 줄로 설치할 수 있습니다. 다양한 전략에 대한 구성 옵션 포함
• 현재 팩토리 메소드가 no-config 팩토리 메소드와 함께 현재 가지고 있는 사전 구성( BuiltInGenericPreconfigurationPlugin )을 수행하도록 하여 모든 역호환성을 만듭니다.

Jdbi 기본값으로 설정하지 않음

나는 매우 강한 의견을 가지고 있지 않지만, 이 모든 것이 사용자 관점에서 매우 복잡하게 들립니다. 사용자는 사용하려는 유형에 대해 가능한 다양한 매핑을 이해하고 적절한 매핑을 선택해야 합니다. 이것은 어려운데, 특히 시간적 요소가 작용할 때 가능합니다. 가능한 다른 옵션을 이해하는 것은 결코 쉬운 일이 아닙니다.

사용자는 사용하려는 유형에 대해 가능한 다양한 매핑을 이해하고 적절한 매핑을 선택해야 합니다.

아니요, 그들이 원할 때만. 기존 팩토리 메소드는 현재와 똑같은 사전 설치된 매퍼를 사용하여 Jdbi 인스턴스를 계속 출력합니다. 우리는 추가로 DIY 구성 팩토리 메소드를 얻을 것이며, 이를 선택하는 사람들은 매핑의 친밀도를 파악해야 할 것입니다. DIY 인스턴스를 얻고 YourDbAndVersionPlugin 설치하고 무엇을 하든 롤링하는 중간도 있을 것입니다. 내 긴 설명은 기준선이 아니라 주로 jdbi 내부 및 고급 사용법이었습니다.

TLDR: 여전히 Jdbi.create(dataSource) 를 할 수 있으며 아직 제공하지 않은 추가 헛소리를 할 필요가 없습니다. 다른 사람은 Jdbi.createBlank(dataSource).install(x).install(y).install(z)...

저는 기존 팩토리를 더 이상 사용하지 않아야 한다고 생각하지 않는다는 점을 제외하고는 참여하고 있습니다. "즉시 사용 가능한" 동작이 꽤 좋기 때문에 대부분의 사용자가 계속 사용할 것이라고 믿습니다.

그럴 수 있지

@TheRealMarnes 이 전체 대화는 JDBC에서 직접 지원하지 않는 JSR-310 데이터 유형을 다루기 시작했습니다.

잘못된 java.time 매퍼와 인수를 제거하고 내장 대신 플러그인에 넣는 것에 대한 합의가 있다고 생각합니다.

아직도 그것을 추구하고 싶습니까?

java.time 것들만? 자바타임플러그인?

예, java.time 유형 전용 플러그인이지만 인수와 매퍼가 @findepi에서 설명한 대로 순진하고 손실이 많은 구현

SimplisticJavaTimePlugin ?

내 다른 PR이 처리 될 때까지 이것으로 기다리십시오. 동시에 너무 많은 것입니다.