오늘은 어디로 갈까...

백수 3일째 본문

白手日誌

백수 3일째

剛宇 2009. 7. 3. 17:34
 현실에서 캐시(cash)가 문제더니, 나만의 세상에서는 캐시(cache)가 문제이다. 
 순수한 OR Mapping이라면 대상 객체에 의해서 추가/수정/삭제가 있어날 경우 캐시(cache)된 내용을 갱신 시키줄 연결고리가 있지만, 생뚱맞게 텍스트로 쿼리를  따로 작성해서 사용할 경우, 어떤 연관관계가 있는지 알아내기가 힘들다. 뭐, 쿼리를 분석하여 대상이 되는 테이블을 추출해내고, 그 테이블에 데이터 변경이 일어날 경우 처리하면 되기도 하지만, 노력에 비해 결과가 별로이다는 것이다. 쿼리 분석하기도 어렵고, 뷰(view)를 쓸 경우는 데이터베이스 종속(?)적인 구현을 할 수 밖에 없으니, 참 난감하다. 쿼리를 작성할때 이 쿼리는 어떤 테이블과 연관관계가 있다고 정의하도록 요구 할 수도 있지만, 그것은 개발자를 너무 괴롭히는것 같으니 없는셈 쳐야하고.... 답이 없구나.. ㅠㅠ
 거기다가 처음에는 캐시 대상을 엔티티(Entity)별로 구분지어서 사용할려고 했어나, 텍스트로 쿼리를 따로 작성해서 사용할 경우 이것 역시 문제가 되었다. 같은 엔티티를 사용한다고 해도, 쿼리 내용에 따라서 제외되는 값들도 있으니, 동일한 키(?)에서 같은 대상을 봐선 안되는 문제가 생겨버릴 수도 있다는 것이다. 이걸 해결하기 위해서는 쿼리별로 캐시를 사용해야한다는 결론에 도달하게 되는데, 문제는 엔티티 기반의 자동 생성 쿼리일 경우에는, 쿼리별로 개별적 캐시 설정을 해줄 방법이 묘연하다는 것이다. 우격다짐으로 현란한 설정 파일을 만들도록 요구하면 해결되기는 하지만, 이것 역시 개발자를 괴롭히는것이내 없는셈 쳐야한다....

 후.. 결론은 역시, 본인은 문제 해결 능력이 없다는 것일까? ^^;;

 너무 많은 생각은 때론 본질을 놓쳐버리고는 하는데, 지금의 나도 그런게 아닐까? 왜 캐시를 사용하려고 했는지, 그 근본으로 돌아가서 다시 한번 생각해봐야겠다....