Hibernate 명명 정책: JPA 사양 및 Spring Boot 관점

매번 우리가 프로젝트에 의존항을 주입할 때마다, 우리는 계약을 체결하는데, 그 중에는 통상적으로 숨겨진 많은 것들이 정교하고 아름다운 인쇄물에 쓰여 있다.이 글은 귀하, Hibernate, Spring Boot 간에 3자 계약을 체결할 때 놓칠 수 있는 것들을 살펴보겠습니다.우리는 명명 전략을 토론할 것이다.

JPA 이름의 기본값

기본 설정에 대한 최종 규칙은 직관적이어야 한다는 것이다.Hibernate를 JPA의 기본 구성으로 사용하는 표준 Spring 부트 응용 프로그램에 이 규칙이 적용되는지 확인합니다.실체'PetType'이 있다고 가정해 보세요.데이터베이스에 있는 어떤 표 이름과 관련이 있는지 알아맞혀 봅시다.
첫 번째 예:

@Entity
public class PetType {
  // fields omitted
}

나에게 있어서 가장 직관적인 표명은 유명PetType이다.PostgreSQL에 대한 테스트를 통해 우리는 관련 표명이 실제로pet_type라는 것을 발견했다.
명시적 설정 이름@Table을 사용하겠습니다.

@Entity
@Table(name = "PetType")
public class PetType {
  // fields omitted
}

이번에 우리는 PetType을 보고 싶지만, 만약 우리가 다시 테스트를 실행한다면... pet_type!
좋아, 우리 인용 부호로 시계 이름을 묶자.이것은 정의된 이름을 보존해야 할 뿐만 아니라 대소문자도 보존해야 한다.

@Entity
@Table(name = "\"PetType\"")
public class PetType {
  // fields omitted
}

다시 한 번, 우리의 기대는 틀렸다. 우리는 보았다“pet_type”. 그러나 지금은 인용이다!

휴면 명명 정책

구글에서'jpa 실체 기본 테이블 이름'을 검색하면 다음과 같은 문제가 발생할 수 있습니다result.

The JPA default table name is the name of the class (minus the package) with the first letter capitalized. Each attribute of the class will be stored in a column in the table.

이것이 바로 우리가 첫 번째 예에서 보기를 바라는 것이지, 그렇지 않습니까?분명히 어떤 것들은 표준을 위반했다.
우리 겨울잠 깊이 들자.문서에 따르면 Hibernate에는 두 개의 인터페이스가 명명표, 열 등을 책임진다. ImplicitNamingStrategy와 PhysicalNamingStrategy.ImplicitNamingStrategy 개발자가 명확하게 명명하지 않은 모든 대상을 명명한다. 예를 들어 실체명, 표명, 열명, 인덱스, FK 등이다. 생성된 이름은 논리명이라고 하는데 Hibernate는 내부에서 이를 사용하여 대상을 표시한다.그것은 결코 데이터베이스에 있는 이름이 아니다.PhysicalNamingStrategy 논리적 JPA 객체 이름을 기준으로 데이터베이스에 사용되는 실제 물리적 이름을 제공합니다.실제로 Hibernate를 사용하면 데이터베이스 대상 이름을 직접 지정할 수 없고 논리 이름만 지정할 수 있다는 뜻이다.엔진 덮개 아래에서 발생하는 일을 더욱 잘 이해하려면 아래 그림을 참고하십시오.

이러한 인터페이스의 Hibernate 기본 구현은 ImplicitNamingStrategyJpaCompliantImpl과 PhysicalNamingStrategyStandardImpl입니다.전자는 JPA 사양에 따라 논리적 이름을 생성하고, 후자는 수정 없이 물리적 이름으로 사용합니다.문서에서 가장 잘 설명되어 있습니다.

JPA defines inherent rules about implicit logical name determination. If JPA provider portability is a major concern, or if you really just like the JPA-defined implicit naming rules, be sure to stick with ImplicitNamingStrategyJpaCompliantImpl (the default).
Also, JPA defines no separation between logical and physical name. Following the JPA specification, the logical name is the physical name. If JPA provider portability is important, applications should prefer not to specify a PhysicalNamingStrategy.

그러나, 우리 프로그램은 다른 행동을 보여 줍니다.그게 왜?Spring Boot은 Hibernate의 기본 인터페이스 구현을 덮어쓰고 SpringImplicitNamingStrategy 및 SpringPhysicalNamingStrategy를 사용합니다.
실제로 SpringImplicitNamingStrategy 복제ImplicitNamingStrategyJpaCompliantImpl의 행위는 연결표 이름에 미세한 차이가 있을 뿐이다.그래서 틀림없이 SpringPhysicalNamingStrategy 우리가 본 결과가 생겼을 것이다.documentation설명은 다음과 같습니다.

By default, Spring Boot configures the physical naming strategy with SpringPhysicalNamingStrategy. This implementation provides the same table structure as Hibernate 4: all dots are replaced by underscores and camel casing is replaced by underscores as well. Additionally, by default, all table names are generated in the lower case. For example, a TelephoneNumber entity is mapped to the telephone_number table.

기본적으로 camelCase와 PascalCase는 항상 snake case로 변환됩니다.사실 이 기능을 사용하면 비 snake 상황을 처리할 수 없습니다.개인적으로, 나는 영원히 camelCase나PascalCase를 사용하여 데이터베이스 대상을 명명하지 않겠지만, 일부 DB 관리자들은 이렇게 할 것이다.만약에 Spring Boot 응용 프로그램이 제3자 데이터베이스를 처리하고 그 중에서pascal이나camel 사례에서 최소한 하나의 표나 열을 정의한다면 기본적인 Spring Boot 설정은 사용자에게 적용되지 않을 것입니다.따라서 지정된 데이터베이스 이름 규약을 지원하는 물리적 이름 정책을 사용해야 합니다.본고에서 기본 이름 정책을 어떻게 바꾸는지 배우거나 필요하면 여기에서 자신의 실현을 제공하는 방법을 배웁니다.
따라서 Hibernate는 JPA 규범에 맞고 Spring Boot은 맞지 않는다. 버그처럼 보일 수도 있지만, Spring Boot은 자기 의견을 고집하는 틀이라고 주장한다.엔진 덮개 아래에서 사용하는 기술의 모든 기준과 규범에 대해 자신의 의견을 적용할 권리가 있다는 얘기다.개발자에게는 다음과 같은 의미가 있습니다.

의견은 어떠한 규범보다 능가할 수 있다.다시 말하면 규범과 기준은 그것이 어떤 모습이어야 하는지를 설명하고 사용된 실현은 그것이 실제로 무엇인지를 정의한다.

어떤 것이 기본적으로 작동한다면 이 기본이 무엇인지, 그리고 그것이 어떻게 작동하는지 항상 알아야 한다.

기본값은 라이브러리 버전 업그레이드에 따라 변경될 수 있으며 예측할 수 없는 부작용을 초래할 수 있습니다.

결론

기본적으로 설정된 마력은 예상치 못한 행동을 할 때까지 계속 작용할 수 있다.이러한 위험을 피하기 위해서, 기본값을 은밀하게 사용하는 것이 아니라, 현식 정의를 더 좋아할 수도 있습니다.그래서 우리의 건의는 다음과 같다.

은밀한 명명 정책이 코드에 영향을 미치지 않도록 항상 JPA 객체를 명명합니다

.

열, 테이블, 인덱스 및 기타 JPA 대상 이름에 snake 대소문자를 사용하여 물리적 명명 정책

을 통해 변환되지 않도록 합니다

만약에 snake 사례가 귀하(예를 들어 남겨진 데이터베이스 사용)에 적용되지 않는다면 물리적 명칭 정책을 PhysicalNamingStrategyStandardImpl로 설정하십시오.

JPA 객체의 명명은 또한 솔리드 클래스 또는 필드 이름이 재구성된 상태에서 데이터베이스 모드를 불필요하게 변경하는 것을 방지합니다.
실행할 때 잠재적인 문제를 해결할 수 있음을 알 수 있습니다. 저희는 명명약정을 도입하여 개발자에게 책임을 이전할 뿐입니다.현재 우리는 모든 개발자가 같은 규칙을 따르도록 확보해야 한다.이것은 이러한 직책을 개발 도구로 한층 더 옮겨 자동화를 실현할 수 있다.

따라서 IntelliJ IDEA를 사용하면 개발자가 JPA, Hibernate, Spring Data JPA, Liquibase 및 기타 관련 기술을 사용할 수 있도록 돕는 플러그인JPA Buddy을 시도할 수 있습니다.JPA Buddy를 사용하면 팀이 액세스할 수 있으며set up agreed code conventions 새로 생성된 JPA 솔리드에 적용할 수 있습니다.