Feat : Post entity 기능구현

[Shsin9797]

🔎 작업 내용

Post 도메인의 테이블, 컬럼값 부분 구현했습니다.

💬 리뷰 요구사항 (선택)

post 랑 comment 를 동시에 작업하면서 번갈아서 push 했는데.. post 랑 comment 나눠서 올라가지않고 섞여서 올라간거같아요... 원래 이렇게 안하고 하나씩 작업해야하나요 ?

📸 이미지 첨부 (선택)

➕ 이슈 링크

• [ Feature/post Feat: Post 기능 구현 #6] Feat: Post 기능 구현 #6

[yunjunghun0116]

고생하셨습니다 :)

[yugyeom-ghim]

고생하셨습니다!

수정 필요한부분 수정해주시면 Approve하겠습니다!

[yugyeom-ghim]

필드명을 member_id라고 작성 안하셔도 Hibernate에서 알아서 memberId라고 했을경우 member_id로 알아서 매핑해주더라구요

저도 어떻게되는건지 궁금해서 찾아봤는데
https://docs.jboss.org/hibernate/orm/6.2/userguide/html_single/Hibernate_User_Guide.html#PhysicalNamingStrategy
여기에서 2.5. Naming strategies 부분 보시면 개발자가 작성한 엔티티 클래스 이름을 논리적 이름으로 결정하고 DB에 사용할때는 물리적 이름으로 변환하다고 하는 내용이 있는데
저희가 정한 이름 memberId를 인식하도록 논리적 이름으로 결정하고 이걸 DB에 저장할때 물리적이름으로 변환해서 member_id로 저장하는거 같더라구요

private Long memberId 이런식으로 작성하시면 좋을 거 같습니다.

[yugyeom-ghim]

column의 length를 기본적으로 지정해주는게 좋을 거 같아요 전에 멘토님께 피드백 받았던 내용인데 DB를 저희가 중간에 바꾸진 않겠지만 DB별로 default column length가 다르다보니 정해주는게 좋다고 하더라구요

[yugyeom-ghim]

createdAt, updatedAt은 RootEntity에 구현돼있어서 따로 작성하지않으셔도 될 거 같아요

[yugyeom-ghim]

@Auth는 생성자에서는 작성하지 않으셔도 되고 Controller에서 memberId가 필요할경우

이렇게 사용하시면 될 거 같습니다!

[Shsin9797]

자세히 설명해주셔서 큰 도움이 됐어요. 감사합니다!

■ 참고 ■

Hibernate의 명명 전략은 객체-관계 매핑(ORM)을 사용하는 개발자들에게 종종 혼란을 줄 수 있는 부분

논리적 이름과 물리적 이름, 무엇이 다른가요?

논리적 이름 (Logical Name):

개발자가 Java 클래스나 속성에 부여하는 이름입니다.
코드 가독성과 유지보수를 위해 의미 있는 이름을 사용합니다.
예: memberId, userAccount

물리적 이름 (Physical Name):

데이터베이스 테이블이나 컬럼에 실제로 사용되는 이름입니다.
데이터베이스 시스템의 제약이나 규칙에 맞춰야 합니다.
예: member_id, user_account

Hibernate의 명명 전략이 하는 일

Hibernate는 개발자가 정의한 논리적 이름을 데이터베이스에 맞는 물리적 이름으로 자동 변환해줍니다. 이 과정에서 다양한 명명 전략을 적용하여 개발자의 편의를 도모합니다.

예시:

개발자가 정의한 엔티티:
@Entity public class Member { @Id private Long memberId; // ... }
코드를 사용할 때는 주의가 필요합니다.

논리적 이름: memberId
물리적 이름: member_id (기본적인 언더스코어(_) 방식 변환)

왜 명명 전략이 필요한가요?

• 데이터베이스 시스템의 제약:
  대소문자 구분, 특수 문자 사용 제한 등 데이터베이스마다 다른 규칙이 존재합니다.
• 코드와 데이터베이스의 일관성 유지:
  개발자가 의도한 이름과 실제 데이터베이스에 저장된 이름이 다르면 혼란을 야기할 수 있습니다.
• 다양한 개발 스타일 지원:
  개발자마다 선호하는 명명 규칙이 다르므로, Hibernate는 다양한 명명 전략을 제공하여 개발자의 선택지를 넓힙니다.

2.5. Naming strategies 부분의 의미

링크하신 Hibernate 문서의 2.5. Naming strategies 부분에서는 Hibernate가 제공하는 다양한 명명 전략에 대해 설명하고 있습니다. 즉, 개발자가 정의한 논리적 이름을 어떤 방식으로 물리적 이름으로 변환할지 설정할 수 있다는 것을 의미합니다.

이 문서는 Hibernate에서 객체 모델을 관계형 데이터베이스로 매핑하는 과정에서 이름을 어떻게 처리하는지 설명하고 있습니다.

2.5. 네이밍 전략
객체 모델을 관계형 데이터베이스로 매핑할 때, 객체 모델의 이름을 대응되는 데이터베이스 이름으로 매핑하는 과정을 설명합니다. Hibernate는 이를 두 단계로 나눕니다:

• 논리적 이름(logical name)을 결정하는 단계:

도메인 모델 매핑에서 논리적 이름을 결정합니다. 논리적 이름은 사용자에 의해 명시적으로 지정될 수 있습니다 (예: @column, @table과 같은 어노테이션을 사용).
또는 Hibernate가 ImplicitNamingStrategy 계약을 통해 암묵적으로 결정할 수도 있습니다.

• 논리적 이름을 물리적 이름(physical name)으로 변환하는 단계:

논리적 이름을 물리적 이름으로 변환하는 작업은 PhysicalNamingStrategy 계약에 의해 정의됩니다.

• 과거의 NamingStrategy 계약
  과거에는 Hibernate에서 org.hibernate.cfg.NamingStrategy라는 단일 계약을 사용했는데, 이 계약은 지금은 개별적으로 나뉜 ImplicitNamingStrategy와 PhysicalNamingStrategy의 역할을 모두 맡고 있었습니다.

그러나 이 계약은 특정 네이밍 규칙을 유연하게 적용하기에 충분하지 않았습니다. API가 결정을 내릴 정보를 제공하지 않거나, API 자체가 잘 정의되지 않았기 때문입니다.

이런 한계로 인해 org.hibernate.cfg.NamingStrategy는 더 이상 사용되지 않고, 대신 ImplicitNamingStrategy와 PhysicalNamingStrategy로 대체되었습니다.

• 네이밍 전략의 핵심 개념
  네이밍 전략의 주요 아이디어는 개발자가 도메인 모델을 매핑할 때 반복적인 정보를 최소화하려는 것입니다.

• Jakarta Persistence 호환성
  Jakarta Persistence는 암묵적인 논리적 이름 결정에 관한 규칙을 정의합니다. 만약 Jakarta Persistence 제공자의 이식성이 중요한 경우, 또는 Jakarta Persistence에서 정의한 암묵적 네이밍 규칙을 선호한다면, 기본 설정인 ImplicitNamingStrategyJpaCompliantImpl을 사용하는 것이 좋습니다.

또한, Jakarta Persistence에서는 논리적 이름과 물리적 이름을 구분하지 않으며, 논리적 이름이 물리적 이름으로 간주됩니다. 따라서 Jakarta Persistence의 이식성을 고려할 때는 PhysicalNamingStrategy를 따로 지정하지 않는 것이 좋습니다.

• 요약
  Hibernate는 객체 모델에서 데이터베이스 이름을 결정하는 두 단계의 네이밍 전략을 가지고 있으며, ImplicitNamingStrategy와 PhysicalNamingStrategy를 통해 논리적 이름과 물리적 이름을 처리합니다. Jakarta Persistence의 이식성을 고려해야 할 경우, Jakarta Persistence의 기본 네이밍 규칙을 따르는 것이 좋습니다.

추가 설명

• ImplicitNamingStrategy: Hibernate가 기본적으로 제공하는 명명 전략으로, 대부분의 경우 자동으로 적절한 물리적 이름을 생성해줍니다.

• PhysicalNamingStrategy: 개발자가 직접 구현하여 더욱 복잡한 명명 규칙을 적용할 수 있는 인터페이스입니다.

• @table, @column 애노테이션: 개발자가 직접 물리적 이름을 지정할 수 있습니다.

결론

Hibernate의 명명 전략은 개발자가 객체 지향적인 방식으로 데이터베이스를 설계하고 관리할 수 있도록 도와줍니다. 논리적 이름과 물리적 이름의 개념을 이해하고, Hibernate가 제공하는 다양한 명명 전략을 적절히 활용하면 더욱 효율적인 개발이 가능합니다.

[Shsin9797]

궁금한사항 : length 지정시 , content 부분에 아래 방법을 사용하는건 어떻게 보시나요?

• 긴 텍스트 저장: 게시글 본문, 댓글 등 긴 텍스트를 저장하는 경우라면 255자는 부족할 수 있습니다. 이 경우 TEXT 또는 CLOB 타입을 사용하는 것이 적절합니다.

게시글 본문: @lob 애노테이션을 사용하여 CLOB 타입으로 설정하는 것이 좋습니다.

@Lob
private String contents; // 긴 텍스트 저장 시

현재는 db에 255 로 저장되고 있게 짰는데, 이거로 충분할지 싶긴합니다 .

[yugyeom-ghim]

Post에서는 255자로 부족 할 수 있겠네요 Comment는 255를 넘을 거 같지는 않아서 유지하고 Post에서는 Lob쓰는거 좋아보입니다!

[Shsin9797]

넵 수정했습니다!

[yugyeom-ghim]

자바에서는 Long으로 했을때 대부분? h2랑 mysql만 확인해봤는데 DB에는 bigint타입으로 저장되더라구요 Long으로 통일해주시면 좋을 거 같습니다!

[Shsin9797]

넵 수정했습니다 !