Hibernate-reactive: JDBC 대신 Vert.x 드라이버를 통한 스키마 내보내기

조금 이상하다. 동시에 동일한 연결 문자열을 구성하는 데 너무 많은 방법을 사용하지 않는 것이 좋습니다. 미래에 사용자는 Rx와 함께 ORM을 사용할 수 있을 것이며 일부 경우에만 Rx API를 사용하기를 원할 것입니다. ORM 사용자에게 이미 친숙한 속성을 사용하는 것도 좋습니다.

아 죄송합니다. 나는 당신이 부동산 이름에 대해 이야기하고 있지 않다는 것을 방금 깨달았습니다.

주로 사용하고 싶은 유스 케이스가 있는지 궁금합니다.
다른 구성 매개변수.
네이티브 반응 드라이버에 특정
속성.

어쨌든 ORM과 유사한 속성을 가져야 할 것 같지만
jdbc 부분이 이름에서 제거되었습니다.
그리고 한 가지 유형의 속성만 설정하면 어떻게 되는지 결정합니다.

2020년 5월 1일 금요일 오후 5시 53분 Andrew Guibert [email protected]
썼다:

같은 이유로 나는 우리가 물건을 만드는 데 지나치게 손을 뻗어서는 안된다고 생각합니다.
편리하다/익숙하다. 예를 들어, 지금 우리는 RX 구성을 지원합니다.
편리하고 친숙하지만 기술적으로는 그렇지 않은 jdbc 프로토콜 URL
JDBC를 사용하지 않기 때문에 정확합니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/hibernate/hibernate-rx/issues/104#issuecomment-622468348 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAEIQ5JHS5PQ7M7APGO2YVLRPL5APANNCNFSM4MXDM4CA
.

어쨌든 ORM과 유사한 속성을 가져야 하지만 이름에서 jdbc 부분이 제거되어야 합니다.

다음과 같은 이유로 표준 JDBC URL 형식을 고수해야 한다고 생각합니다.

• 그것은 표준이다
• 데이터베이스 공급업체에 의해 잘 문서화되어 있습니다.
• 모두가 이미 알고 있다
• Hibernate RX 와 일반 Hibernate 또는 일반 JDBC를 동시에 구성하는 것이 더 쉽습니다.

@DavidD OP에서 문제를 제대로 설명하지 않았을 수 있지만 구성 매개변수는 스키마 생성에 어떻게 적용됩니까?

이 문제에 대한 의도를 다시 설명하기 위해 JDBC 드라이버 또는 jdbc 전용 구성을 포함할 필요 없이 테이블 자동 삭제/생성 절차를 수행할 수 있다고 제안합니다(RX가 동일한 속성을 다시 사용하는 경우 , 그래도 괜찮아)

아 죄송합니다. 나는 당신이 부동산 이름에 대해 이야기하고 있지 않다는 것을 방금 깨달았습니다.

네, 알겠습니다. 내 잘못이야. 처음이라 너무 빨리 읽었다.

앱이 RX만 사용하는 경우 사용자에게 JDBC 드라이버를 추가/구성하도록 요구하는 것은 다소 어색해 보입니다.

이 문장은 이미 ORM에 존재하는 JDBC 설정에 대한 속성을 사용한다는 사실에 대해 이야기하고 있다고 생각하게 했습니다. 우리가 그것에 대해 이야기했다는 것은 여전히 ​​좋은 일이며 지금은 변경할 계획이 없습니다.

그래서 이전에는 JDBC를 통해 스키마 내보내기를 수행하는 것이 완벽하다고 주장했습니다. (반응형 스키마 내보내기란 무엇입니까?)

그러나 @emmanuelbernard 및 @Sanne 과의 전화 대화에서 이것이 실제로 Quarkus 사용자에게 잠재적인 고충점이라는 사실을 알게 되었습니다.

@guibert 가 이에 대해 나에게 경고하려고 할 때 나는 더 많은 관심을

따라서 어쨌든 이것은 우리가 우선순위를 두어야 하는 문제입니다. 비록 초기 릴리스를 위해 제 시간에 완료될 수 없다고 생각하지만 말입니다.

이상한 생각 - 내가 정말 몰라서 어리석은 일이라면 용서해 주세요 - 하지만 반응형 드라이버를 JDBC 호환 어댑터로 래핑한 다음 스키마 생성 코드에 입력할 수 있는지 궁금하십니까?

나는 그것이 schemagen 도구를 용이하게 할 수 있다면 그러한 작업이 과도하다고 생각하지만 아마도 더 많은 용도가 있습니까?

@산네

여기에 GenerationTarget 라는 추상화가 있습니다. 우리는 그것을 구현할 수 있을지 모르지만, 하나를 연결하는 방법에 대해 정확히 100% 확신할 수는 없습니다.

실패할 경우 스키마 내보내기 도구에 SCRIPT 내보내기를 요청한 다음 명령을 하나씩 DB에 전송하면 됩니다.

우리는 그것을 구현할 수 있을지 모르지만, 하나를 연결하는 방법에 대해 정확히 100% 확신할 수는 없습니다.

문제는 이러한 대상 목록이 새 대상을 추가할 확실한 방법 없이 하드코딩된 것처럼 보인다는 것입니다. 그러나 코어에 대한 작은 수정은 이를 해결하기에 충분할 수 있습니다.

확인. 이것이 여전히 최우선 순위는 아니지만 가능한 한 다음 ORM 릴리스를 연기할 것이므로 누군가가 시간을 찾을 경우를 대비하여 마지막 순간 패치를 더 포함할 수 있습니다.

참고로 릴리스를 수행하는 데 실제로는 20분 정도 소요된다는 점을 기억하십시오. 그러나 실제로 사용하기 전에 Maven 중앙 동기화와 모든 것을 기다려야 합니다.
이는 Reactive 릴리스가 가능하기 전에 약 24시간 동안 릴리스해야 함을 의미합니다.

나는 이것을 시도하기 위해 시간을 할애할 것이다. 아마도 그것은 매우 간단합니다. 알아보겠습니다.

아마도 그것은 매우 간단합니다. 알아보겠습니다.

따라서 실제로 비교적 간단했지만 내가 고려하지 않은 문제가 발생했습니다. Hibernate Reactive는 더 이상 JDBC 메타데이터에 액세스할 수 없으며, 이는 일부 결과를 가져오지만 너무 끔찍하다고 생각하지 않습니다. 다행스럽게도 Hibernate는 JDBC 메타데이터가 매우 불안정하고 그것에 의존하지 않을 때 작성되었습니다.

괜찮을 것 같아요.

또한 Hibernate Reactive가 실제로 데이터베이스에서 스냅샷을 얻기 위해 JDBC 연결을 사용하는 ForeignKeys 의 버그를 노출했습니다! 해당 문제에 대한 별도의 버그 보고서를 열겠습니다.

굉장합니다, 감사합니다!

Gavin의 수정 사항은 ORM에 병합되었습니다. 이제 스키마 생성이 가능해야 합니다.

자동화된 스키마 업데이트가 훨씬 더 복잡하다고 생각합니다. 첫 번째 컷에서는 이것이 덜 중요하다는 데 동의할 수 있습니까?

Gavin의 수정 사항은 ORM에 병합되었습니다. 이제 스키마 생성이 가능해야 합니다.

감사 해요.

자동화된 스키마 업데이트가 훨씬 더 복잡하다고 생각합니다.

오, 현재 구현이 전적으로 JDBC 메타데이터인 IIRC를 기반으로 하기 때문에 훨씬 더 어렵습니다.

첫 번째 컷에서는 이것이 덜 중요하다는 데 동의할 수 있습니까?

네, 이 단계에서 작업할 생각은 전혀 없습니다. 필요하다고 생각하지도 않습니다.

@Sanne 그 변경 사항이 포함된 ORM 코어가 출시되기

@gavinking 우리는 월요일에 출시를 계획할 수 있습니다. 하지만 더 많은 변경 사항이 필요할 수 있다면 연기하는 것이 최선인지 궁금합니다.
우리는 또한 Quarkus가 필요로 하는 몇 가지 다른 수정 사항에 대해 작업하고 있습니다. 그래서 우리가 원할 때마다 하나를 릴리스할 수 있지만 나중에 더 많은 수정 사항을 릴리스할 수 있습니다.

@Sanne 꼼짝마요 , 그 댓글은 제가 #113의 심각성을

@gavinking 어느 시점에서 Hibernate에 필요한 DB 메타데이터의 종류를 설명하는 Vertx-sql-client에 대한 문제를 작성할 수 있습니까? Vertx 클라이언트는 언젠가 현재보다 더 나은 메타데이터 API를 갖게 될 것입니다.

앤드류를 위해 +1!

Postgres용 메타데이터 가져오기 API를 구축하려는 이니셔티브가 있습니다.
https://github.com/eclipse-vertx/vertx-sql-client/pull/513. 피드백은
확실히 이 문제를 중심으로 더 나은 일반 API를 구축하는 데 도움이 됩니다.

2020년 5월 14일 목요일 오후 9시 58분 Andrew Guibert [email protected]
썼다:

@gavinking https://github.com/gavinking 어느 시점에 쓸 수 있습니까?
DB 메타데이터의 종류를 설명하는 Vertx-sql-client 문제
최대 절전 모드에 필요합니까? Vertx 클라이언트에는 더 나은 메타데이터 API가 있어야 합니다.
언젠가는 현재보다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/hibernate/hibernate-reactive/issues/104#issuecomment-628654875 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/ABJV4JODSAYQT7BG2TWHZI3RRP2JFANCNFSM4MXDM4CA
.

스키마 관리 도구에 필요한 것은 information_schema.tables 의 정보에 대한 액세스이며 information_schema.key_column_usage 도 마찬가지입니다.

스키마 관리 도구에 필요한 것은 information_schema.tables 의 정보에 대한 액세스이며 information_schema.key_column_usage 도 마찬가지입니다.

한 가지 옵션은 information_schema 를 쿼리하여 해당 정보를 직접 가져오는 것입니다. 역사적으로 플랫폼의 차이점을 추상화하기 위해 JDBC 메타데이터 API만 사용했습니다.

이건 끝났어!

그리고 그것은 사용자에게 매우 투명한 방식으로 수행됩니다. JDBC 드라이버 또는 연결 풀이 설정되어 있으면 Hibernate ORM은 JDBC를 통해 스키마 내보내기를 수행하지만 JDBC 드라이버가 없으면 스키마 내보내기를 수행합니다. Vert.x 드라이버가 시작됩니다.

굉장해!
정말 감사합니다

그리고 그것은 사용자에게 매우 투명한 방식으로 수행됩니다. JDBC 드라이버 또는 연결 풀이 설정되어 있으면 Hibernate ORM은 JDBC를 통해 스키마 내보내기를 수행하지만 _iff_ JDBC 드라이버가 없는 경우 스키마 내보내기를 통해 Vert.x 드라이버가 시작됩니다.

그냥 궁금해서 JDBC 접근 방식을 먼저 사용해야 하는 이유는 무엇입니까? vertx를 통해 실행할 수 있는 기능이 있다면 항상 실행하지 않는 이유는 무엇입니까?

관련 없는 일부 연결이 설정되고 있기 때문에 다른 동작이 트리거되는 경우 사용자에게 혼란을 줄 수 있습니다. 또한 - 다른 연결이 실제로 동일한 DB를 가리키는지 어떻게 알 수 있습니까?

그냥 궁금해서 JDBC 접근 방식을 먼저 사용해야 하는 이유는 무엇입니까? vertx를 통해 실행할 수 있는 기능이 있다면 항상 실행하지 않는 이유는 무엇입니까?

일반 JDBC 드라이버로 설정한 일반 Hibernate가 있다면 왜 사용하지 않습니까? 반응형 스키마 내보내기는 의미가 없습니다. 이것이 제대로 작동하도록 하려면 마지막에 완전히 불쾌한 join() 를 수행해야 합니다.

다른 연결이 실제로 동일한 DB를 가리키는지 어떻게 알 수 있습니까?

동일한 JDBC URL이기 때문에?