Conversation
|
수혁님 안녕하세요~ 실패하는 테스트가 있습니다. |
|
수정해서 다시 푸시했습니다! |
There was a problem hiding this comment.
굿굿~ 과제 잘해주셨네요. 수고하셨습니다.
(1)
FETCH JOIN으로 DB 네트워크 통신을 절감하는 것과 메모리와는 관계가 없습니다. 아마 엔티티 캐싱과 섞인? 질문 같습니다.
DB 통신에 일반적으로 수십~수백 밀리세컨드가 걸리는데요. 어떤 쿼리냐에 따라 더 걸릴 수도 있습니다.
JPQL이 아무래도 쿼리를 직접 짜야하다보니, 어느 정도 성능에 절충이 가능한 상황이라면 굳이 안써도 됩니다. 상황에 맞게 판단하면 될 것 같습니다.
별개로 메모리 접근 비용(엔티티 캐싱)은 음.. 마이크로세컨드 단위 정도로 나왔던 것 같습니다.
(2)
ManyToMany는 직접 코드로 보이는게 아니라, 예상치 못한 쿼리가 날라갈 수 있기 때문에 주의해야 합니다.
다대다 관계에서 단순히 테이블들을 연결만 해주면 되는 경우도 있지만 부가 정보가 필요한 경우도 있습니다.
이 때 결국 OneToMany, ManyToOne을 사용해야합니다.(ManyToMany는 칼럼으로 외래키만 가질 수 있음)
(3)
클라이언트에서 필요로하는 정보의 단위가 꼭 엔티티로 떨어지는 것은 아닙니다. 클라이언트가 필요로 하는 응답은 application layer에 정의되어있을 텐데요. 결국 데이터 변환은 필요합니다.
저희는 단일 모듈로 웹 어플리케이션 서버를 개발하고 있는데요. 개발해야하는 앱이 서버만 있는 것은 아닙니다.
주기적으로 데이터를 처리하는 배치앱을 만들 때도 있는데요. 이 때 레이어를 구분해서 모듈로 나눠두면, 배치앱과 서버앱이 적절히 필요한 모듈을 공유하는 구조를 짤 수 있습니다.
| @GeneratedValue(strategy = GenerationType.IDENTITY) | ||
| @Column(nullable = false) | ||
| val id: Long = 0L, | ||
| @Column(unique = true) |
| TODO() | ||
| val playlist = playlistService.get(id) | ||
|
|
||
| var isLiked = false |
| throw PlaylistNeverLikedException() | ||
| } else { | ||
| playlistLikeService.delete(playlistId = id, userId = user.id) | ||
| return ResponseEntity.status(204).build() |
| ) { | ||
| TODO() | ||
| ) : ResponseEntity<Unit>{ | ||
| if (playlistLikeService.exists(playlistId = id, userId = user.id)) { |
There was a problem hiding this comment.
요 로직은 서비스 안에 들어가는 것이 더 좋을 것 같습니다.
|
|
||
| @Query("SELECT pg FROM playlist_groups AS pg LEFT JOIN FETCH pg.playlists") | ||
| fun findAllOpenGroups(): List<PlaylistGroupsEntity> | ||
| @Query("SELECT p FROM playlists AS p " + |
| throw UserNotFoundException() | ||
| } | ||
|
|
||
| if (playlistLikesRepository.findByPlaylistIdAndUserId(playlistId, userId) != null) { |
2 participants
추가과제는 시간 나는 대로 구현해 보겠습니다...!