영속성 컨텍스트 쓰기 지연 SQL 저장소

[질문 템플릿]

1. 강의 내용과 관련된 질문인가요? (예)

2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)

3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)

[질문 내용]

persist 하면 캐시에 저장됨과 동시에 그 내용이 SQL로 해석되어 쓰기 지연 SQL 저장소에 저장되잖아요.

그런데 중간에 영속화 했던 것의 값을 바꾸면 updata문이 또 추가가 될거 잖아요. (커밋 시점에 비교하는 거니 한번만. 물론 보통 persist 전에 모든 작업을 끝내놓는게 바람직 하지만)

그런 것 보다는 차라리 캐시 될 때 쓰기 지연 SQL 저장소에다 SQL문으로 해석하여 저장하는 것 보다,

커밋 순간에 캐시에 있는 내용들을 SQL문으로 해석하는 것은 별로일까요?

그러니까, member 객체를 select문에서 가져온거면 enum.select, 새로 생성한 거면 enum.create라고 해서 추가로 그렇게 묶어서,

캐시에 저장할 때는 원래 member 객체 reference를 가지고 있도록 한 다음 객체 하나로 감싸서 저 enum을 가지고 있게 한다던지,

(초기상태 캡쳐도 한다고 했는데, 그럼 원래 이런 식인건가..? Member prototype 해서..?)

마지막에 commit 순간에 영속성 컨텍스트를 읽어 SQL문으로 해석하고

만약 enum.create면 그냥 최신값 그대로 쿼리문으로 만들어서 날리면 되고

update면 현재값 그대로 날리면 되고

select면 이거는 똑같고.

전체적으로 보니

그냥 이거 모두를 select 처럼 commit 시점에 한번 확인만 하고 영속성 컨텍스트에 있는 모두를 한번에 쿼리로 바꿔 내보내는 것이요.

근데 이거 아직 join 이런 게 잘 몰라서 그런 쪽에서 문제가 있을 수 있겠나요?