제약 조건 위반 시 사용자 친화적 오류 메시지를 제공할 수 있는 방법이 있습니까?
열이 있다고 치자.Gender
제약 조건CHECK( Gender IN ('F', 'M', 'OTHER'))
.
실수로 클라이언트 측에서 이 문제를 처리하는 것을 잊어버린 경우 사용자는 sm을 다음과 같이 볼 수 있습니다.
ORA-02290: check constraint (SYS_C099871244) violated
사용자에게도 그다지 도움이 되지 않으며, 유지보수나 디버그를 하는 개발자에게도 도움이 되지 않습니다.
(사이비)와 같은 개발자 정의 메시지를 제공하는 방법이 있습니까?자바의
assert Gender IN (0,1):'Gender must be F or M'
내가 생각할 수 있는 유일한 방법은 제약 조건을 BEFORE UPDATE OR INSERT 트리거로 이동하고 실패 시 실행하는 것입니다.Raise_Application_Error( code, my_message )
. 하지만 나는 싫어요.
의견에 따라 구체적인 이유를 나열한 편집 목록
1. 저는 가능한 한 데이터에 가까운 논리를 유지하고 싶습니다.
2. 최종 사용자 Raise_Application_Error 메시지는 응용 프로그램 메시지와 구별할 수 없습니다.
3. 개발자는 애플리케이션을 우회하여 데이터에 액세스하더라도 좋은 메시지를 볼 수 있음
4. 트리거로 제약 조건을 이동하는 것이 못생겨서(그렇습니까?) Raise_Application_Error와 다른 smth를 찾아야 합니다.
EDIT21, 5년 후, 그리고 내가 db 관련 일을 떠난 후, 마침내 내가 이것에 대해 정말로 좋아하지 않는 것 - 코드 복제.서버와 클라이언트 측에서 정확히 동일한 논리를 반복해야 합니다.아마도, 두개의 다른 언어로.그리고 그들을 동기화시켜요.이건 그냥 못생겼어요.
답이 분명하게 말해주듯, 이에 대해서는 제가 할 수 있는 것이 없습니다.그래서 이제는 제가 좋은 시민이 되어 마침내 답을 받아들여야 할 때입니다. (미안해요, 그냥 잊어버렸어요.)
제약 조건은 데이터베이스가 사용자가 아닌 잘못된 응용프로그램으로부터 자신을 보호하기 위해 사용하는 것입니다.
즉, 제약 조건 위반을 응용 프로그램에서 캡처하고 사용자에게 제공하기 위해 정리해야 합니다.저는 그렇게 하지 않은 애플리케이션이 어떤 면에서는 부족하다고 생각합니다.
당신의 지원서(적어도 이 경우에는) 그런 일이 일어나지 않을 것이기 때문에 저는 '가능성이 있다'고 말합니다.그것은 거의 확실히 그런 것에 드롭다운 제한된 선택 제어 장치를 사용해야 합니다.콤보박스나 (충격, 공포) 자유 형식의 텍스트 입력 필드를 사용했다면 이를 재정의해야 합니다.
이는 애플리케이션과 제약 조건이 어느 시점에서 동기화되지 않는 한 위반이 발생하지 않는다는 것을 의미합니다.하지만 이는 고객이 여러분의 애플리케이션을 손에 넣기 훨씬 전에 테스트 과정에서 포착해야 할 사항입니다.
실제 질문에 답하려면 제약 조건 위반으로 Oracle에서 나오는 메시지를 변경할 수 없습니다.최종 사용자가 이해할 수 있도록 제약 조건의 이름을 지능적으로 지정하는 것이 최선입니다.
하지만 저는 여전히 사용자에게 문제를 제시하는 것은 데이터베이스 계층이 아니라 애플리케이션 계층의 책임이라고 주장합니다.
예외 메시지 "ORA-02290: check constraint (SYS_C099871244) veriated"를 "ORA-20001: Gender는 F 또는 M이어야 합니다"와 같은 다른 메시지로 대체하도록 Oracle에 항상 지시하는 방법을 찾고 있는 경우 대답은 "아니오, 할 수 없습니다.
당신이 할 수 있는 것은 개발자들이 코드로 사용할 수 있는 다음과 같은 솔루션을 제공하는 것입니다.
...
begin
insert into emp (empno, gender) values (p_empno, p_gender);
exception
when others then
error_pkg.handle_exception;
end;
그error_pkg.handle_exception
procedure는 Oracle 예외 메시지를 구문 분석하여 제약 조건의 이름을 추출하고(제약 조건 위반인 경우), 해당 제약 조건 이름을 교차 참조 테이블에서 찾아 필요한 메시지를 가져온 다음 사용합니다.raise_application_error
새 메시지로 예외를 다시 적용할 수 있습니다.
Oracle은 이와 같은 패키지와 테이블을 표준으로 제공할 수 있다고 생각하지만 실제로는 시스템의 오류 처리에 대한 여러 가지 요구 사항이 있기 때문에 일반적으로 충분히 유용하지 않다고 생각됩니다.
간단히 말해서:
내가 아는 맞춤형 처리를 위해 오라클 오류를 잡아낼 방법이 없습니다.하지만 저는 당신이 어쨌든 그렇게 하려고 노력하면 안 된다고 생각합니다.
긴 버전:
당신의 이유 뒤에 숨겨진 의도는 좋지만...
저는 가능한 한 데이터에 가까운 논리를 유지하고 싶습니다.
논리는 가능한 한 데이터에 가까워야 합니다. 이는 사실입니다. 그러나 이것은 논리가 아닙니다. 이것은 이미 정의된 논리에 대한 예외를 식별하는 코드의 프레젠테이션이며 프레젠테이션은 데이터 또는 논리 계층(오류 메시지의 도메인이 시스템의 모든 부분에 걸쳐 있고 클라이언트 측에서 서버에 걸쳐 있음)과 혼합되어서는 안 됩니다.ide, 번역, 일관성 있는 업데이트, 메시지 관리 및 개요 등도 고려해야 합니다.)
최종 사용자 Raise_Application_Error 메시지는 응용 프로그램 메시지와 구별할 수 없습니다.
맞는 말이지만, 그 반대의 경우에도 유효하므로 특별히 관련이 없습니다. DB 오류 코드의 중앙 저장소, 응용 프로그램 오류 코드 및 오류 처리가 이를 처리하는 경우 어느 계층이 오류 메시지를 표시하는지는 (최종 사용자의 경우) 무관합니다.또한, 장기적으로는, 일을 절약할 수 있다는 것이 확실하지 않습니다.
개발자는 애플리케이션을 우회하여 데이터에 액세스하더라도 좋은 메시지를 볼 수 있음
이것은 사실입니다, DB에 직접 접속하는 개발자들에게는 더 좋은 오류 메시지가 있을 것입니다.그러나 여기에는 몇 가지 코멘트가 적용됩니다. 복잡한 시스템에서 애플리케이션 계층을 우회하는 것은 허용되지 않아야 합니다(개발자의 경우에도). 허용된다면 개발자는 제약 조건 이름에서 오류 메시지를 찾을 위치를 알 수 있을 것입니다(오류 코드와 메시지의 중앙 저장소는 동일한 DB에 유지되어야 합니다).
트리거로 제약 조건을 이동하는 것이 못생겨서(그렇습니까?) Raise_Application_Error와 다른 smth를 찾아야 합니다.
그것은 프레젠테이션이고 DDL에 있어서는 안 된다는 점에서 추합니다. 또한 트리거를 통해 행해질 경우 부당한(?) 수행 불이익이 발생합니다(얼마나 큰지, 얼마나 우아하게 행해질 수 있는지 알 수 없습니다).
참고: DBMS 오류 처리에 연결할 수 있는 좋은 기능이 될 것이라는 데 전적으로 동의합니다.
그러나 오류 처리 및 오류 메시지 처리는 다음과 같은 속성을 갖습니다.
- 유지보수가 가능해야 합니다. (이론적으로는 사용자 지정 오류 메시지를 정보 스키마에 저장하여 깨끗하게 수행할 수 있지만 SQL 표준에는 명시되어 있지 않으므로 이는 순수하게 이론적인 설명입니다. 실제로는 이러한 목적을 위해 자신의 테이블이 있어야 합니다.)
그리고 더욱 중요한 것은
- 오류 메시지 처리는 상황에 민감합니다(그리고 오류 처리기는 데이터 클라이언트의 관점에서 가장 잘 알 수 있습니다). 때로는 동일한 오류 코드에 다른 프레젠테이션, 다른 메시지가 필요할 수도 있습니다.)
제약 조건이 클라이언트에 제기되었든 지원을 통해 (잠재적) 분석을 위해 파일에 로그인되었든 간에 보다 유용한 메시지가 있어야 합니다.
제약 조건을 지정하면 더 도움이 됩니다.
나는 뭔가를 위해 가고 싶습니다.
ALTER TABLE blah ADD CONSTRAINT blah_gender_ck CHECK ( Gender IN ('F', 'M', 'OTHER'));
언급URL : https://stackoverflow.com/questions/6068792/is-there-way-to-give-user-friendly-error-message-on-constraint-violation
'programing' 카테고리의 다른 글
TCP 프로토콜이 아닌 파일 소켓과 연결하는 방법? (0) | 2023.09.10 |
---|---|
유형의 일치하는 빈이 없습니다...종속성이 있는 것으로 확인됨 (0) | 2023.09.10 |
json 또는 html 파일을 사용하여 jQuery ajax를 사용하여 테이블 자동 새로 고침/업데이트 (0) | 2023.09.10 |
MySql 경고 트래핑 (0) | 2023.09.10 |
부트스트랩 3 Navbar(로고 포함) (0) | 2023.09.10 |