2009-11-24 2 views
0

방금 ​​프로젝트를 시작하고 지옥에서 프로젝트를 물려 받았습니다. 지옥 = {2 년 이상 지나치게 복잡하고 오라클과 SQL 서버를 모두 사용}IBatis SQL Maps 유지 관리/자동 생성?

Oracle 서버에는 100 개 이상의 저장 프로 시저가 있으며 각 인스턴스에는 IBatis SQL Map이 있습니다. 일부는 동일한 결과 맵을 공유합니다. DBA는 매일 상점 procs를 바꾸고 싶지 않고 알려주지 않습니다.

질문 : 해결책에있는 모든 IBatis SQL Maps를 검사 할 수있는 도구가 있습니까? 이상적으로는 확인할 것 :

  1. 저장 프로 시저
  2. 저장 프로 시저 매개 변수는
  3. 저장 프로 시저 결과 [열 이름] 결과지도
  4. 스토어에서 사람과 일치하는 매개 변수 맵에있는 것들과 일치 존재 프로 시저 결과에 결과 맵에 지정된 값이 누락되지 않습니다.
  5. 결과 맵의 오브젝트 특성 제목은 결과 맵에 나열된 오브젝트 특성 제목과 일치합니다.

배경 : 일반적으로 SQL Server 및 SubSonic 2.2 만 ORM으로 사용합니다. 이렇게하면 명령이 실행되고 DAL은 마술처럼 자동 생성됩니다. 필요한 열이 없으면 컴파일 시간 오류를 이해하기 쉽고 런타임 오류가 혼동되지 않습니다. 여기에 사용할 수있는 비슷한 도구가 있습니까?

도움 주셔서 감사합니다.

답변

1

Ibator이라는 도구가 있지만 설명하는 대상이 아닌 것 같습니다. 내 접근 방식은 iBatis 코드를 사용하는 테스트를 작성하는 것입니다. 그런 식으로 테스트가 실패하면 뭔가 잘못되었다는 것을 알게됩니다. 다른 방법으로는 오라클의 metadata을 사용하여 절차 등의 존재 여부를 테스트하는 것입니다. 이러한 검사는 추가 테스트 일 수 있습니다.

0

오라클을 만진 이후로 꽤 오랜 시간이 걸렸지 만 올바르게 호출 한 경우 저장 프로 시저 (예 : select)의 출력이 어디에도 선언되어 있지 않습니다. 따라서 도구로 리버스 엔지니어링 할 수 있어야합니다. LinqToSql은 SQL Server에서 부분적으로 성공을 거두려고하지만 일반적으로 어렵고 신뢰할 수없는 프로세스입니다. 그래서, 그것은 코드 gen/tooling으로 달성 할 수없는 것 근처에서 목록에 항목 3-5을 만드는 것처럼 보일 것입니다. 스토어드 프로 시저에 대한 SubSonic 2.2의 지원에 대해 너무 깊이 파고 들지는 않았지만, 3-5 항목과도 ​​어려움을 겪을 것이라고 생각합니다. 반대로 저장 프로 시저의 일부로 선언 된 단일 출력 필드는 처리하기 매우 간단합니다.

항목 1 & 2는 훨씬 더 달성 가능하지만, iBatis에서 사용할 수있는 툴링에는 익숙하지 않습니다. 나는 이바티스 또는 오라클이 정말로 당신의 문제와 관련이 있다고 생각하지 않습니다.

최상의 방법은 DBA가 저장 프로 시저 변경 사항을 감지하고 수동으로 처리하기 위해 diff를보다 유용하고 적극적으로 실행하도록 유도 할 수 있습니다.