[Spring + iBatis + Oracle] select query with function call

How can I querying select list after Oracle function call

파주에서 개발중에 생전 첨 보는 문데에 맞딱뜨렸다.
오라클 함수를 호출해서 서버와 세션을 맺어야 리스트 조회가 가능한 것이다.
흐흠...

그냥 생각에
function call 먼저 한 번 날리고,
그다음에 list query  날리면 될 거라는 초딩 수준의 생각을 했다면 결과는 뻔하다.
조회 안된다!

오라클 세션도 세션인지라,
하나의 세션 안에서 쿼리를 해야 조회가 되는 것이다.

PL/SQL 클라이언트 프로그램이야 당연히 DB 오픈하면서 세션을 물고 가기 때문에
함수 호출과 쿼리를 두번에 조회해도 조회가 되는 거였다.


그래서 생각해낸 대안은 이랬다.
1. function 와 select query 를 하나로 묶어서 procedure 를 만든다... 이거는 일이 더 커지므로 비추!!
2. select query 바로 앞단에 function call 을 해볼까?

<select id="getList" parameterClass="java.util.Map"  resultClass="map">
                { call my_pkg.my_function(....
<![CDATA[
SELECT ....
해보면 아시겠거니와, 에러난다.

3. 마지막으로 At last!!!
하루동안 고민끝에 트랜잭션에 묶어보면 어떨까?
정말로 될까 긴가민가 했다. 결론은 됐다!!


<select id="getList" parameterClass="java.util.Map"  resultClass="map">
<![CDATA[
SELECT ....


<procedure id="myMkgFuncCall" parameterClass="java.util.Map">
<![CDATA[
call my_pkg.my_function(....


자바에서 호출할 때,

UserDefinedRowHandler rowHandler = new MyRowHandler();
try {
sqlMapClientTemplate.getSqlMapClient().startTransaction();
sqlMapClientTemplate.getSqlMapClient().queryForObject("myMkgFuncCall", map);
sqlMapClientTemplate.getSqlMapClient().queryWithRowHandler("getList", map, rowHandler);
sqlMapClientTemplate.getSqlMapClient().endTransaction();
} catch (SQLException e) {
e.printStackTrace();
}



참고로 MyRowHandler 는 iBatis RowHandler 를 상속받아서 간단히 만들면 된다.
아마도 RowHandler 를 안쓰고 queryForList 로 해도 될 것 같다.

Sns 개발하기 #2. 기획, 아키텍처

후덜덜 아이패드에서 작성하다가 사진찾으러 나가갔다가 와보니 글 쓰던거 다 날라갔네...

기획에대해...

거두 절미하고, 

sns 는 단순해 보이지만,  한페이지 안에  많은 개발요소가 존재하기 때문에 기획 단계에서 세심한 배려가  필요하다. 그렇지 않으면 개발자가 자칫 구현해야할 기능을 오해하거나 심지어 개발을 안해버릴수도 있다.

실전에서 문제가 발생한 사례로,

기획자가 나름 디테일하게 정의하는 과정에 초안은 심플했지만,

갈수록 디테일을 추가하다보니 처음 30장이던 기획서가 거의 세배가 되어버렸다.

게다가 기능이 여기저기 엉키다 보니 1페이지에서 못다 기술한 내용이 40, 50 페이지에 나오기도하고

이정도는 예측하겠지 하고, 생략하거나, 카피앤 페이스트로 넘겨버린 뒷페이지에서 혼동을 발생하기도 했다.

내 생각은 이렇다.

큰 기획페이지를 보여주고, 디테일한 기능이 있다면 체크 표시를 해주고 인덱싱을 했더라면 좋았을 것같다.

아래 캡쳐를 예로들어서,

1, 2 는 바보가 아닌 이상 누구나 예상할 수 있다.

3, 4, 5 는 별것 아닌것 같아서 기획자로 기능이 있다고 표시까진 해주지만 사실 개발자 입장에서는 의외로 생각할게 많은 기능이다. 생각이 많이 필요하다는 것은, 성능, 구조 즉 아키텍처와 직결된다.

6,7 은 정말 자세히 명기해주지 않으면 개발자가 모르거나 잘못구현할수 있는 기능이다.

그것도 몰랐냐고 하면 할말없구... ㅋㅋ  난 몰랐으니까능...

A 의 경우도 저런 기능이 있다는 표시만 해놓으면 개발자는 참으로 난감하다.

아키텍처 얘기로 넘어가보자.

3번의 좋아요를 얘로 들어보자.

sns 라는건 개인대 개인의 이슈 드리븐이다. (이건 그냥 내 표현이다.)

기존의 게시판 개발로 생각한다면 굳이 개발할 수 없지는 않겠지만, 역시 뭔가 찜찜하다.

a가 b한테 좋아요를 했는데 관계형 db의 좋아요 테이블에 넣었다 뺐다 해야 할까?

내가 했던 프로젝트에서는 유저 폴더에 파일을 떨구기로 했다 (내 아이디어는 아니었다)

정확히는 좋아요는 아니었고, 알람이나 공지가 왔을 때 그리 하기로 했다.

그러다보니 회원마다의 폴더 생성하는 메카니즘이 회원 가입 시점에 들어가야 했고, 관련 정보를 가져올때 db와 폴더를 같이 조합해야하는 조회 매카니즘이 필요했다. 이건 바른걸까?

내가 처음 제안했던 방식은 회원별 이슈테이블이었다.

똑같이 회원 가입 시점에 회원고유 테이블 생성 메카니즘이 필요했고, 조회시 관련내용을 조합하는 메카니즘이 필요하게된다. 하지만, db-파일 조합 메카니즘과, db-db 조합 메카니즘... 둘중에 후자가 좀더 낫지 않을까?

내가 가장 하고싶은 이야기는 윗부분이다.

그외에 필요했던 몊가지 아키텍처를 붙여본다.

- 데이터 비동기 로딩 처리 (요즘 뭐 많이하는...)

- html 과 js 바인딩 (jstl 없는 바인딩)

- ui 어플리케이션과 api 어플리케이션 분리

- java web restful service

-node.js 로 알람, 채팅 실시간 양방향 처리

이정도...

다음에는 아키텍처 그림 몇장을 넣어볼까한다.