Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/채팅 엔티티 정의 및 채팅 신청 비즈니스 로직 구현 #148

Merged
merged 3 commits into from
Jan 8, 2025

Conversation

rudeh1253
Copy link
Collaborator

이슈 번호

#136

개요

채팅에 필요한 엔티티 정의하고 채팅 신청을 구현했습니다. 서비스 로직만 구현했고, 추후 채팅 기능 구현이 어떻게 되는가에 따라 서비스 로직이 변경될 수 있겠습니다.

@rudeh1253 rudeh1253 added Feature New feature or request Test Test code labels Dec 13, 2024
@rudeh1253 rudeh1253 requested a review from dlrkdus December 13, 2024 11:18
@rudeh1253 rudeh1253 self-assigned this Dec 13, 2024
@rudeh1253 rudeh1253 mentioned this pull request Dec 26, 2024
Copy link
Collaborator

@dlrkdus dlrkdus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

제가 리뷰가 늦어서 반영하긴 힘드실 것 같고 궁금한 점만 여쭤봤습니다!

*
* @param reader 채팅을 읽는 회원 엔티티
*/
public void readIfOpponent(Member reader) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

이건 개인적인 의견이긴 한데, 채팅 읽음 메서드는 채팅방 진입시마다 호출되므로 DB 부하가 커지는데, 그에 비해 메세지 읽음 데이터가 반드시 영속성을 가져야 하거나, 다른 속성과 연결될 일이 있는지 고려해보는 것도 좋을 것 같아요 ! 저는 아니라고 판단해서 Redis에서 관리했던 경험이 있습니다.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

좋은 의견 감사합니다! 이 점에 대해서 고민해 보겠습니다


@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "member_id")
private Member member;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

채팅 메세지는 대량 데이터인데 멤버와 매핑까지 시킬 필요 있을까요?? 저라면 memberId만 속성으로 지정했을 것 같은데 이유가 궁금합니다.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

db상에서는 chat_message와 members 사이에 외래키로 연관관계를 맺고 있는데 JPA 엔티티에서는 Long memberId만 가지고 있는 걸 말씀하시는 거죠?
db에서 서로 외래키로 연관관계를 맺고 있는 엔티티끼리는 습관적으로 매핑을 해 왔기 때문에 Member와 매핑을 시켰습니다. 그런데 연관관계 매핑을 설정하지 않고 Long 타입의 memberId만 필드로 가지게 한다면 Member 객체 인스턴스를 생성할 필요가 없기 때문에 메모리를 훨씬 아낄 수 있다는 이점이 있을 것 같네요. 추가적인 이점이 있다면 알려주시면 감사하겠습니다!

@dlrkdus dlrkdus merged commit 69e70c8 into develop Jan 8, 2025
@rudeh1253 rudeh1253 deleted the Feature/chat-request-buiz-logic#136 branch January 8, 2025 23:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New feature or request Test Test code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants