개발자 도구 · UUID 생성기
Nil 및 Max UUID: 두 가지 특수 값 및 사용 시기
· 배경
uuid 개발자 워크플로 데이터 유효성 검사
모두 0인 Nil UUID은 2005 이후 표준에 포함되었으며 전체 F Max UUID는 2024에 합류했습니다. 이 게시물에서는 그 용도, 검증자와 상호 작용하는 방법, 피해야 할 센티널 가치 실수에 대해 설명합니다.
ID가 00000000-0000-0000-0000-000000000000인 행 — 자리 표시자가 프로덕션 버그가 되는 방법
식별자가 00000000-0000-0000-0000-000000000000인 행은 생성된 식별자와 다른 의미를 전달하면서 UUID 모양으로 보일 수 있습니다. 애플리케이션이 "아직 할당되지 않음"이라는 값을 자동으로 사용하는 경우 완료되지 않은 모든 행은 동일한 표시를 공유합니다. 허용된 UUID 이름을 실제 객체로 가정하는 코드는 일반 키인 것처럼 자리 표시자에 대해 요청, 캐시 또는 조인을 요청할 수 있습니다. 눈에 보이는 형식은 비즈니스 규칙을 전달하지 않습니다. 명시적인 감시 계약만이 가능합니다.
한 레이어는 자리 표시자에 대해 알고 있고 다른 레이어는 모르면 생산 버그가 시작됩니다. 양식은 Nil을 제출할 수 있고 API는 이를 승인할 수 있으며 지속성 레이어는 이를 저장할 수 있으며 다운스트림 작업자는 null이 아닌 모든 문자열을 사용 가능한 외래 키로 처리합니다. 실패는 Nil의 형식이 잘못되었다는 것이 아닙니다. ToolAcre는 의도적으로 이를 인식합니다. 실패는 "유효한 텍스트", "생성된 식별자" 및 "할당된 관계"가 확인되지 않은 하나의 조건으로 축소되는 것을 허용하는 것입니다.
Nil UUID — 정의 및 모든 버전 및 변형 검사가 기술적으로 실패하는 이유
확인된 구현에서 Nil은 모두 0으로 구성된 정식 문자열입니다. 일반 UUID 패턴이 테스트되기 전에 전용 분기를 수신하므로 정규식에 1부터 8까지의 버전 숫자와 8부터 b까지의 RFC 변형 니블이 필요한 경우에도 isValidUuid는 true를 반환합니다. InspectionUuid는 동일한 예외를 따릅니다. 유효한 값을 보고하고 버전 0을 할당하며 UUID가 모두 0비트이고 무작위가 아니라고 말합니다. 이는 모든 검증자가 동일한 선택을 해야 한다는 일반적인 주장이 아니라 검증된 애플리케이션 동작입니다.
Nil은 생성된 식별자에 사용되는 일반적인 버전 및 변형 경로를 전달하지 않기 때문에 해당 분기가 중요합니다. ToolAcre 버전-4 값은 버전 위치에 4을 전달하고 변형 위치에 8, 9, a 또는 b 중 하나를 전달합니다. Nil은 두 곳 모두에서 0을 전달합니다. 예외를 언급하지 않고 해당 검사를 "실패"라고 부르는 것은 오해의 소지가 있습니다. 체커는 먼저 특별한 값을 인식한 다음 의도적으로 일반적인 패턴을 우회합니다. 소비자가 그것을 받아들인다면 똑같이 눈에 띄는 주문이 필요합니다.
Nil UUID은(는) 버전 0로 보고된 ToolAcre의 명시적으로 유효한 예외입니다.
all-f 문자열 ffffffff-ffff-ffff-ffff-ffffffffffff는 이 저장소에서 특별한 분기를 수신하지 않습니다. 또한 f가 허용되는 버전 범위를 벗어나고 허용되는 RFC 변형 니블 세트를 벗어났기 때문에 일반 패턴에도 실패합니다. 결과적으로 ToolAcre는 이를 Nil처럼 취급하지 않고 비정규적인 것으로 보고합니다. 통합 문서에서는 Max의 표준화 기록과 범위 경계 목적을 설명하지만 도구 기록, 구현, 테스트 중 어느 것도 이러한 주장을 확인하지 않으므로 이 기사에서는 이를 반복하지 않습니다.
이 차이점은 지원되지 않는 기록보다 더 유용합니다. Nil은 테스트된 동작을 가진 명명된 상수인 반면 Max는 검사기가 거부하는 입력입니다. 프로젝트는 자체 프로토콜에서 추가 감시 의미 체계를 정의할 수 있지만 해당 선택은 ToolAcre에서 추론되어서는 안 됩니다. 상호 운용성이 all-f 값 수용에 달려 있는 경우 해당 규칙을 문서화하고 소유 시스템에서 테스트하십시오. 모든 라이브러리가 UUID 모양의 문자열을 동일하게 분류한다고 가정하지 마십시오.
all-f Max 값은 ToolAcre에 의해 거부됩니다. RFC 기록이나 의도된 범위 사용이 주장되지 않았습니다.
센티널과 null 값은 스키마에서 그렇게 명시한 경우에만 서로 다른 질문에 대답합니다. Null은 관계가 없음을 직접적으로 나타낼 수 있습니다. Sentinel은 열을 채워진 상태로 유지하고 주변 인터페이스가 Null을 전달할 수 없는 경우 유용할 수 있지만 데이터처럼 보이는 값을 생성하므로 인덱스, 조인, 직렬 변환기 및 캐시를 통해 이동합니다. 명백한 편리함은 책임을 모든 독자에게 전달합니다. 각 독자는 허용된 UUID이 할당된 엔터티의 이름을 지정하지 않는다는 점을 기억해야 합니다.
센티널이 관계의 의미를 충족하지 않고 외래 키 모양 검사를 충족할 수 있으면 해당 거래는 함정이 됩니다. 또한 알 수 없음, 의도적으로 할당되지 않음, 삭제됨, 아직 처리되지 않음 등의 고유한 상태를 흐리게 할 수도 있습니다. 이러한 상태가 동작에 영향을 미치는 경우 하나의 매직 식별자를 오버로드하는 대신 명시적으로 표현하세요. 호환성을 위해 Nil을 유지하는 경우 상태에 하나의 문서화된 의미를 부여하고 다른 곳에서는 이를 거부하며 비즈니스 코드 전체에 걸쳐 비교를 분산시키는 대신 명확하게 소유된 경계에서 변환합니다.
유효성 검사기 및 특수 값 — 엄격한 버전/variant 검사가 Nil 및 Max를 거부할 수 있는 이유와 거부 여부를 결정하는 방법
ToolAcre는 하나의 유효성 검사기 내부에 두 개의 레이어를 보여줍니다. 일반 입력이 잘리고 선택적 외부 중괄호가 제거되며 나머지 문자열은 표준 8-4-4-4-12 레이아웃과 허용되는 버전 및 변형 위치에 대해 확인됩니다. Nil은 해당 패턴 이전에 테스트되었으며 의도적으로 허용되었습니다. Max에는 예외가 없으며 실패합니다. 이는 호출자가 정규식만으로는 특수 값 정책을 예측할 수 없음을 의미합니다. 패턴을 둘러싼 제어 흐름은 검증 계약의 일부입니다.
세 가지 질문을 분리하여 자신만의 정책을 설계하십시오. 첫째, 경계가 허용하는 형식으로 텍스트를 인식할 수 있습니까? 둘째, 값이 일반 UUID입니까 아니면 명명된 예외입니까? 셋째, 해당 카테고리가 이 필드 및 작업에 허용됩니까? 생성 엔드포인트는 진단 구문 분석기가 Nil을 인식하더라도 Nil을 거부할 수 있는 반면, 가져오기 경계는 문서화된 레거시 Nil 마커를 null로 변환할 수 있습니다. 해당 결과를 별도로 반환하면 "파서가 이를 승인함"이 실수로 결과를 저장하도록 승인되는 것을 방지할 수 있습니다.
ToolAcre는 Nil을 명시적으로 허용하고 버전 및 변형 패턴에 따라 Max를 거부합니다.
"할당되지 않음"을 의미하는 Nil을 사용하는 담당자 식별자가 있는 작업 테이블을 생각해 보세요. WHERE Assignee_id IS NOT NULL로 작성된 쿼리는 할당된 작업을 선택하는 것처럼 보이지만 센티널은 구체적인 문자열이기 때문에 모든 Nil 행도 선택합니다. 그런 다음 조인은 해당 키를 가진 사용자가 없으면 해당 행을 삭제하여 덜 명확한 두 번째 결과를 생성할 수 있습니다. 두 쿼리 모두 지역적으로 합리적입니다. 스키마가 할당을 직접 노출하는 대신 평범해 보이는 식별자 내부에 상태를 숨겼기 때문에 그들은 동의하지 않습니다.
지속 가능한 수정은 할당을 할당으로 모델화하는 것입니다. 즉, 스토리지 계약에서 허용하는 경우 null 허용 관계를 사용하거나 여러 상태를 구별해야 하는 경우 명시적 상태를 추가합니다. 호환성 경계가 여전히 Nil을 보내는 경우 지속성 전에 한 번 변환하고 해당 경계에 대해서만 매핑을 되돌립니다. 그런 다음 생성된 버전-4 값, Nil, Max, 빈 입력 및 잘못된 형식의 텍스트를 별도의 사례로 테스트합니다. 애플리케이션은 일반 형식 검사에서 반환되는 답변을 상속하는 대신 각 결과를 결정해야 합니다.
요점: 특수 값은 명시적인 처리가 필요합니다. ToolAcre 생성기로 실제 ID를 생성하고 Nil 및 Max를 의도적인 예외로 처리합니다.
특수 값의 모양은 애플리케이션의 의도를 전달할 수 없기 때문에 명명된 처리가 필요합니다. ToolAcre는 Web Crypto에서 일반 버전-4 UUID를 생성하고 필요한 경우 randomUUID에서 getRandomValues로 대체하고 안전하지 않은 무작위 소스 사용을 거부합니다. 그러면 검사자는 생성된 값을 명시적으로 인식된 Nil 예외와 구별할 수 있습니다. 따라서 이 도구는 관찰에 유용하지만 데이터베이스 감시 정책을 선택하거나 허용된 식별자가 기존 레코드에 속한다는 것을 증명하지는 않습니다.
새로운 식별자에 생성기를 사용하고 모든 센티널을 별도의 프로토콜 결정으로 처리합니다. 현재 검사기에서 Nil은 유효하며 버전은 0이며 무작위가 아닙니다. 맥스는 거절당했습니다. 페이지를 테스트할 때 이러한 구별을 유지한 다음 두 값 중 하나를 허용하기 전에 이를 언어, 데이터베이스 및 API의 규칙과 비교하십시오. 안전한 시사점은 의도적으로 좁혀졌습니다. 생성된 ID, 파서 예외, 누락된 관계 및 비즈니스 상태는 서로 다른 개념이며 강력한 경계로 인해 서로 다르게 유지됩니다.