Whiteship's Note


영어 공부 계획

모하니?/English : 2009. 7. 28. 21:39


읽기부터 자신감이 생길 만큼 충분히 하자.

- 말하는 사람의 속도로 책을 읽어도(1문장 당 1~2초) 이해하고 넘어갈 수 있는 정도.
- 다양한 문법 형태도 구분할 수 있을 정도로 문법 이해 합시다.
- 문장 표현, 어휘 마스타.
- 시드니 셀던 책을 보자.
- 그래머 인 유즈로 문법 공부.

읽기가 어느 정도 된다면 듣기를 하자.

- 원고를 구할 수 있는 짧은 뉴스를 완벽하게 듣는 연습을 하자.
- 받아쓰기.
- 취약한 리스닝 부분을 고쳐나가기
- CNNeZ

말하기, 쓰기는.. 위에 것들을 충분히 하다보면 자연스레 어느정도는 길러지리라 믿는다. 뭐 그건 또 그 때가서 방법을 알려주시겠지/

'모하니? > English' 카테고리의 다른 글

[BBC News] Naples pizza protected by EU  (5) 2010.02.18
[BBC News] Ukraine and Russia argue about spies  (2) 2010.02.17
[EGIU] Unit 19, 20정리  (0) 2009.09.02
[EGIU] Unit 13, 14 정리  (0) 2009.08.11
[EGIU] 20090807 Unit 9, 10 정리  (0) 2009.08.07
20090801 Unit 7, 8 정리  (2) 2009.08.01
090731 Unit 5, 6 정리  (6) 2009.07.31
090730 Unit 3, 4 정리  (0) 2009.07.30
090729 Unit 1, 2 정리  (6) 2009.07.29
영어 공부 계획  (2) 2009.07.28
영어 공부하자  (4) 2009.07.21
top

  1. Richpapa 2009.07.28 22:30 PERM. MOD/DEL REPLY

    저도 읽기에 올인을 했었는데(http://richpaparyan.tistory.com/167), 지금은 생각이 다릅니다. 영어의 요소가 6개라면(어휘, 문법, 리딩, 리스닝, 라이팅, 스피킹) 그 중 리딩-라이팅이 한 묶음이고 리스닝-스피킹이 한 묶음임을 깨달았습니다.

    그런데 아무리 생각해봐도 따로따로 해서는 원하는 영어를 구사하기는 힘들어 보이더라구요. 글쎄 사람마다 스타일이 있어 거기에 맞게 하면 되겠고, 지향하는 목표도 각각 다르겠지만...

    저는 원서사서 읽고 그 원서 오디오북 구해서 듣고 받아쓰고 30분씩 읽고 있습니다. 이것도 하다보니 참... 못할 짓, 몹쓸짓이네요. 그런데 2-3년은 해볼라고 노력중이죠.

    그런데, 기선님은 번역도 하실만큼 리딩은 충분하지 않나요?

    참, 전에 지금까지 학습하신 로드맵을 한 번 부탁한 적이 있는데... 혹시 정리가 되셨다면 공개해 주실 수 있나요?

    Favicon of http://whiteship.tistory.com BlogIcon 2009.07.28 23:21 PERM MOD/DEL

    아핫.. 로드맵 요청하셨던 분이시군요.
    아직 정리해본적이 없어서요;; @_@

    흠.. 번역이랑은 좀 다른 것 같아요.
    기술서적 영어는 DDD같은 책이 나이고서야..
    쉬운편이니까요.

    로드맵이라;; 한 번 그려보지요.

Write a comment.


[하이버네이트] OneToMany에 FetchType.EAGER 사용시 어떤 일이 생길까?

모하니?/Coding : 2009. 7. 28. 20:28


Plan -> PlanDetail 관계에서 Plan 쪽에서 PlanDetail로 OneToMany 관계를 설정하고, fetch 모드를 EAGER로 설정하면,, 엄청난 문제가 생길 수 있습니다. @_@

P 1 <-- PD 1
P 1 <-- PD 2
P 2 <-- PD 3
P 3

이렇게 PD 두 개가 같은 P에 속해있을 경우, P 목록을 뿌리고자, createQuery("from P").list(); HQL로 이렇게 작성하면.. 쿼리는 다음과 같이 날아가게 됩니다.

(양방향 관계에서 mappedby 설정했다고 가정하면..)
~~ from P p left outer join PD pd on p.id = pd.p_id ~~

(양방향 관계에서 mappedby를 설정하지 않았다고 가정하면.. 이건 거의 최악)
~~ from P p left outer join P_PD p_pd on p.id = p_pd.p_id ~~

LEFT OUTER JOIN 인거죠...ㄷㄷㄷ..

결과는 아래와 같은 모습일 겁니다.

P 1 - PD 1
P 1 - PD 2
P 2 - PD 3
P 3 - null

그래서 DB에서는 레코드가 한 줄인데, 화면에는 두 줄이 나타납니다. 크하하하..  그런데.. 이게 .. 이상한 일일까요? 글쎄요. 그런 것 같진 않습니다. P가 가지고 있는 컬렉션을 EAGER 패치로 가져오란 얘기가 곧 DB 관점에서는 P를 왼쪽에 두고 LEFT OUTER JOIN해서 P와 연관 맺고 있는 PD도 가져오란 얘기가 될 테니.. 하이버는 그저 시킨대로 한 죄 밖에는 없습니다. 결국 자연스러운 일입니다.

그렇다면 애초에 원했던 결과는 무엇이었을까요? 바로 P 목록만 가져오는 것이었습니다. 그러려면 P를 가져올 때 PD는 내비두고 오로지 P만 가져오게 해야겠죠. 어차피 P 목록을 보려고 하는데 PD 까지 가져올 필요는 없자나요. 패치모드를 LAZY로 바꾸면 from Plan 같은 HQL을 보내면 아예 join을 하지 않습니다.

~~ from P ~~

아마도 이런 SQL을 보시게 될 겁니다.

논외로  하이버 HQL, Criteria로 발생하는 SQL 쿼리를 이해하는 개발자가 되는 길은 멀고도 험한듯 합니다.

예를 들어 이번 이슈(P->PD)에서 패치모드, 방향성, mappedby의 변화로 생기는 쿼리 형태를 조사하려면 몇 가지 경우의 수를 고려해야 할까요?

- 방향성: 총 2가지(P->PD, P<->PD)
- 패치모드: 총 2가지(P->PD Lazy, P->PD Eager)
- mappedby: 총 2가지(P의 pd에 붙인 @OneToMany에서 mappedby="p")

정답은 그렇다면 2 * 2 * 2 = 8 가지? 글쎄요.

몇 번 해보시면 MappedBy 설정은 거의 영향이 없다는 걸 아실 수 있습니다. mappedby를 하면 좋은 점은 연관 테이블 수를 줄일 수 있다는 것. 하지만 결과에 영향이 없는 이유는 연관 테이블(P_PD)과 PD의 row 수가 같기 때문이죠. P가 PD와 left outer join을 하나, P가 P_PD와 left outer join을 하나 결과는 같으니까요.

따라서 2 * 2 = 4 가지 일까요? 그런데 만약 전제로 했던 P -> PD로의 방향성이 PD -> P 방향성 이라면?? ManyToOne이 되는데, 이때는 어떤 변화가 있을까요? @OneToMany의 fetch 속성 기본값은 LAZY 입니다. 별다른 설정을 하지 않으면 위와 같이 원하지 않았던 결과는 발생하지 않겠죠. 하지만 @ManyToOne의 fetch 속성 기본값은 EAGER입니다. 어떻게 될까요? 무슨 일이라도 생길까요? 앞선 경우처럼 DB에 들어있는 PD의 갯수보다 더 많은 PD의 갯수가 출력될까요?

그렇진 않습니다. ManyToOne 관계니까 그럴리는 없습니다.

PD 1 <- P 1
PD 2 <- P 1
PD 3 <- P 2
            P 3

PD를 왼쪽에 두고 left outer join을 해봤자. 이런 관계라고 할 때 결과는 다음과 같겠죠.

PD 1 - P 1
PD 2 - P 1
PD 3 - P 2

결과 row과 PD row와 동일한 상태가 됩니다. 따라서 ManyToOne에서도 fetch 모드를 별도로 설정하지 않더라도 HQL로 from PD를 날리면 예상하던(?) 결과를 얻을 수 있습니다. ㅎㅎ 재밌지요.
top

Write a comment.