Hibernate-reactive: hibernate.jdbc.time_zone은 TIME 열에서 지원되지 않습니다.

이론상 이미 작동해야 합니다 :-)
https://github.com/hibernate/hibernate-reactive/issues/667

내가 봐줄게

사용 중인 엔티티의 예를 지나칠 수 있습니까? 재생산이 더 좋을 것입니다. JBang을 사용하여 예제 테스트 케이스를 시작할 수 있습니다.

jbang init -t mysql-reproducer@hibernate/hibernate-reactive Issue856.java
jbang edit --open=idea --live Issue856.java

idea 를 좋아하는 IDE로 바꿀 수 있습니다.

신경쓰지 마.... 예외가 보여

더 많은 세부 사항을 위해 Entity에서 LocalTime을 사용하고 데이터베이스에서 TIME을 사용하고 있습니다.

실재
public class A { @Column(name = "time") private LocalTime time; }

테이블
CREATE TABLE IF NOT EXISTS A ( time TIME )

따라서 여기서 문제는 구역화된 _time_의 개념이 완전히 깨져 SQL에 도입되어서는 안 된다는 것입니다(다행히도 대부분의 데이터베이스는 이를 지원하지 않습니다). 시간대 간의 매핑은 _날짜에 따라 다르므로_ 시간대가 지정된 날짜 시간만 의미가 있습니다.

지금까지 나는 hibernate.jdbc.time_zone 의 동작에 대해 전혀 몰랐습니다. 첫눈에 보기에 꽤 나빠 보였고 아마도 H6에서 변경해야 할 것입니다.

그래서 여기서 무엇을 해야 할지 잘 모르겠습니다. ORM과 같은 나쁜 일을 하도록 "수정"하거나 시간으로 작업할 때 설정을 무시하시겠습니까?

아니면 속성을 완전히 무시하고 대신 연결 속성을 사용하여 이 작업을 수행하는 방법을 알아내겠습니까? (Vert.x 클라이언트에 새로운 기능이 필요할 수도 있지만 확실하지 않습니다.)

"버그" 라벨을 제거하겠습니다. 존 시간이 작동하지 않는 것은 버그가 아닙니다. 그것들은 _design_에 의해 망가졌습니다.

(물론 이것은 내가 #676을 할 때 더 깊이 파고들지 않고 hibernate.jdbc.time_zone 의 동작에 문제를 알아차린 것에 대한 부분적인 내 잘못입니다.)

나는 여기서 토론을 시작했다.

시간대 간의 매핑은 _날짜에 따라 다르므로_ 시간대가 지정된 날짜 시간만 의미가 있습니다.

좋아, 하지만 그들은 시간대가 연결되어 있지 않고 변환이 필요하지 않은 LocalTime 를 저장하려고 합니다.
내가 뭔가를 놓치고 있습니까?

그러나 그것은 이 속성이 하는 일이 아닌 것 같습니다. ORM에서는 시간대를 사물에 첨부합니다.

적어도 나에게는 그렇게 보인다. (나는 그 JDBC 메소드의 의미를 완전히 이해할 수 없었다.)

ORM과 동일한 나쁜 일을 하도록 "수정"

ORM이 하는 일을 확인하고 똑같이 할 것이라고 생각합니다. 그것은 아마도 ORM에 익숙한 사용자들이 예상할 수 있는 동작일 것입니다.

ORM이 하는 일을 확인하고 똑같이 할 것이라고 생각합니다.

하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하 달콤한여름아이

ORM은 본질적으로 문서화되지 않은 의미를 가진 JDBC 메소드를 호출합니다.

(그리고 아마도 모든 데이터베이스에서 다르게 작동합니다.)

Zulip 에서 @yrodiere와의 토론 일부를 요약하자면:

1. 그는 모든 JDBC 드라이버가 깨지기 쉽고 다른 작업을 수행하기 때문에 이 모든 것이 처음부터 ORM에서 매우 취약하고(아마도 고장날 수 있다고) 말합니다.
2. hibernate.jdbc.time_zone (주어진 Timestamp 를 Vert.x SQL 클라이언트에 전달하기 전에 주어진 시간대로 변환하려고 시도함)를 사용하여 Timestamp 를 처리하기 위해 내가 결정한 것은 다음과 같습니다. 또는 강력하지 않을 수도 있지만 Time 에 대해 개념적으로 올바르지 않은 것 같습니다.

따라서 옵션은 (1) 설정을 조용히 무시하거나, (2) 설정이 있을 때 폭파하거나, (3) 문제가 있는 것으로 알고 있는 작업을 수행하는 것입니다.

나는 (2)와 함께 갈 의향이 있다.

나는 _가정_ 우리가 현재 날짜 시간에 하고 있는 일을 계속할 수 있고 시간에 관한 설정은 무시할 수 있습니다. 그러나 이런, 그것은 이미 깨진 부분에 대해 새롭고 다르게 깨진 해석을 도입하는 것과 같습니다. 브르르

@pqab 이 설정을 정확히 사용하는 이유는 무엇입니까? 합리적으로, 예를 들어 그것을 사용하지 _않을_ 수 있습니까?

@pqab 왜 이 설정을 _정확하게_ 사용합니까? 합리적으로, 예를 들어 그것을 사용하지 _않을 수 있습니까?

@Ngosti2000에 대한 동일한 질문

공정하게 말하면 LocalTime 와 같은 시간대가 없는 개체에 적용할 것으로 예상하지 못했습니다.

나는 그것이 전역 속성이라는 것이 문제라고 생각하고 다른 경우에 합리적이기 때문에 설정하면 특정 필드에 대해 비활성화 할 수있는 방법이 없다고 생각합니다. 아니면 있을 수 있습니까?

공정하게 말하면 LocalTime 와 같은 시간대가 없는 개체에 적용할 것으로 예상하지 못했습니다.

맞아요. 우리는 제정신을 너무 많이 가정했습니다.

특정 필드에 대해 비활성화하는 방법이 없다고 생각합니다. 아니면 있을 수 있습니까?

내가 아는 한에서는 아니다.

다른 DATE 필드에는 전역 속성이 필요하지만 TIME 필드에는 시간대가 없기 때문에 무시되어야 한다고 예상했습니다.

완료