많은 도움이 되었습니다.
그런데 DBCP가 생성한 객체에서 OID나 Collection을 꺼내는 게 불편하지만 불가능한것은 아니라고 하신거 같은데요.
1. 정확한 절차나 예제를 올려 주실수 있나요?
네이버 개발자 센터에 올라온
PreparedStatement pstmt = con.prepareStatement(sql);
DelegatingStatement d_stmt = (DelegatingStatement) ((DelegatingStatement) pstmt).getDelegate();
CUBRIDPreparedStatement cubrid_stmt = (CUBRIDPreparedStatement) d_stmt.getDelegate();
이걸 시도해 보니 마지막 줄에서 PoolablePreparedStatement를 CUBRIDPreparedStatement 로 캐스팅 못한다고 오류가 나네요.
그리고 그다지 추천하지 않는 방법이라고 하셨는데,
제가 생각하기에는 특정 WAS에 의존적이 된다는것과, 성능저하가 있을것 같다는것 같은데
2. 그 이외의 문제가 있나요?
가능하면 DBCP를 사용하고, OID나 Collection의 직접 입출력은 최소화시키는 방법으로 구현하려 합니다.
또, 혹시 차후버전에서 getOID, getCollection같은 확장된 메소드를
3. 처음부터 표준에 존재하는 getRowId, getArray 등이나, getObject로 지원하실 계획은 없는지 알고싶습니다.
1. 두번째 문장까지 수행된 후에 d_stmt.toString() 값을 확인해보시기 바랍니다.
toString()으로 반환되는 클래스 이름이 jdbc 드라이버에서 생성된 클래스 이름을 확인할 수 있을겁니다.
그리고 반환된 object에 대해 d_stmt.getClass().getName() 과 같은 방법으로 해당 object의 클래스 이름을 확인할 수 있을겁니다.
getDelegate() 함수를 여러번 호출해야 할 수 있으니 각 단계에서 실제 어떤 클래스인지를 확인해보기 바랍니다.
2. SQL을 통해서만 사용한다면 특별히 문제될만한건 없습니다.
collection을 사용할 경우 CUBRID는 다른 타입에 대한 collection (heterogeneous set) 을 지원하고 있지만,
이런 경우는 모델링도 어렵지만, java의 array를 통해 전달할수 없어서 사용할 수 없습니다.
예를 들어 set(int, string)과 같은 타입으로 컬럼을 생성할 수는 있지만, 데이터 입출력은 되지 않으니, 한가지 타입으로 사용하기 바랍니다.
3. RowID, getArray등 지원은 아직 고려하고 있지 않습니다.
그렇지만, oid나 collection모두 Object타입으로 받거나 보낼수 있으므로 크게 문제되지는 않을겁니다.
collection타입의 경우, 예를 들어 set(string) 타입이라면 String[]로 캐스팅하여 값을 꺼내고, String[]를 setObject를 통해 전달할 수 있습니다.
OID의 경우 CUBRIDOID 에서 확장된 메소드를 사용하면 OID를 String형태로 저장하는 것이 가능하고,
저장된 값으로 CUBRIDOID 객체를 직접 만드는 것이 가능하지만, 이런 형태로 OID에 대한 세부적인 핸들링은 좋지 않습니다.
select의 결과로 나온 object를 다른 테이블에 입력하는 등의 과정에서는 oid를 핸들링할수 밖에 없겠지만, 이 경우에는 Object 자체를 전달하는 정도로 사용하는 것이 좋습니다.