inner side

난 왜 지금까지.. dml에 대해 매개변수로 do를 전달햇을때.. pk등 키값을 제대로 처리를 안햇었을까?

예를 들어..  xxDAO클래스의  int update(DO do) 메서드라면,.. (insert도 포함)

지금까지 내경운.. sql 쿼리를 "update 테이블 이름 set 칼럼1 = do.칼럼1, 칼럼2 = do.칼럼2" 

요렇게 했었는데.. 난 바보였다.. 요런 쿼리면.. 모든 로우에 대해 해당 값으로 덮어쓰게 된다.

이런 메서드는 updateAll() 이런 식으로 명명했어야 했다.

update() 라면..

update 테이블 이름 set 칼럼1(pk아님) = do.칼럼1, 칼럼2 = do.칼럼2 ... where 테이블 칼럼.pk = do.pk 

요렇게 했어야 했다... 

난 뭘한건가?????????????????????

오버 로딩으로 중복 코드 줄이겠다는 마음만 앞서서.. (쿼리 구문 ? 에 입력값들 매핑 하는 로직)

update, 와 select를 묶어버리고;; (이것도 위의 삽질처럼.. updateAll과 update 구분못함.. 물론 delete , deleteAll 도 구분 못함)

insert와 delete를 묶었을거다;; 

난 진짜 바보다;;;

db의 테이블.. 그리고 pk.. where 조건절과 서비스 메서드의 조건(selectById...) 구분을 못했었다. 

dml이 왜 dml이냐!!!!! dql 왜 dql이냐??? 왜 두가지 문장이 구분되는 것인지..  좀 깨닫자!!!!!!

select란 dql은 ... 전체 집합에서 조건을 찾는 문법이다.;;; 아.. 그래도 늦게나마 깨달았다;;;

아하하..

일단 가정하는 것이.. core api들이 제공하는 클래스,메서드 등은 뻑날 확률이 거의 없다.

put이라는 메서드의 도큐먼트 설명을 제대로 보지 않고,

애초엔 구현만 시키자고 만들다가..(svn으로 프로젝트 생성도 안함) 

기왕 만들거 내가 공부한것들 적용시켜보자는 욕심에

계속 만들고 부수고 하면서 설계를 계속 바꾸다가.. 버전 관리가 안됐다.

내 생각의 변화, 고민들.. (enumerte 역시 처음엔 c/c++ 처럼 접근을 했는데.. 실제 사용하다

보니까 클래스 였다) 

(ex) ConfigData.DB_INFO_INDEX.DB_LOGIN_ID.ordinal();   <--요렇게 사용했었음;;

계속 같은 소스 파일에서 뒤집어 엎어버리다 보니까 ... 분실했다 ㅠㅠ

=>배운점: 간단한 프로그램이라도 svn을 통해 버전 관리를 할것!!!!

(추가)

현재 svn -> 내 로컬에 저장소 만들고 (visual 어쩌고) -> 이클립스에서 커밋,체크아웃 하고있다. 요거.. 익숙해 져야 한다.

(추가)

git를 공부했다. 연동이 안된다. gitHub .. 클라우드상 저장소로.. 요걸 사용하면 좋을듯 하다.