開発者ツール · UUID ジェネレーター
Nil と Max UUID: 2 つの特別な値とそれらを使用する場合
· 背景
uuid 開発者ワークフロー データ検証
オールゼロの 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 はそれを意図的に認識します。この障害により、「有効なテキスト」、「生成された識別子」、および「割り当てられた関係」が 1 つのチェックされていない状態に崩壊します。
Nil UUID — その定義、およびすべてのバージョンとバリアントのチェックが技術的に失敗する理由
チェックされた実装では、Nil は正規のすべてゼロの文字列です。通常の UUID パターンがテストされる前に専用ブランチを受け取るため、正規表現で 1 から 8 までのバージョン番号と 8 から b までの RFC バリアント ニブルが必要な場合でも、isValidUuid は true を返します。 InspectionUuid は同じ例外に従います。有効な値を報告し、バージョン 0 を割り当て、UUID がすべてゼロ ビットでランダムではないことを示します。これは検証されたアプリケーションの動作であり、すべてのバリデーターが同じ選択をしなければならないという一般的な主張ではありません。
Nil は、生成された識別子に使用される通常のバージョンとバリアントのルートを通過しないため、この分岐は重要です。 ToolAcre version-4 値は、バージョン位置に 4 を持ち、バリアント位置に 8、9、a、または b のいずれかを持ちます。 Nil は両方の場所でゼロを運びます。例外について言及せずにこれらのチェックを「失敗」と呼ぶのは誤解を招く可能性があります。チェッカーは最初に特別な値を認識し、次に設計により通常のパターンをバイパスします。消費者がそれを受け入れる場合、同様に目に見える注文が必要です。
Nil UUID は、ToolAcre の明示的に有効な例外であり、バージョン 0 として報告されます。
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 は、関係の不在を直接表すことができます。センチネルは列にデータが設定された状態を維持し、周囲のインターフェイスが null を保持できない場合に便利ですが、データのように見える値を作成するため、インデックス、結合、シリアライザー、キャッシュを通過します。見かけの利便性により、すべての読者に責任が移されます。各読者は、受け入れられた UUID が割り当てられたエンティティの名前を指定していないことを覚えておく必要があります。
センチネルが関係の意味を満たさずに外部キーの形状チェックを満たせる場合、その取引は罠になります。また、不明、意図的に割り当てられていない、削除された、またはまだ処理されていないなどの個別の状態をぼかすこともできます。これらの状態が動作に影響を与える場合は、1 つのマジック識別子をオーバーロードするのではなく、それらを明示的に表します。互換性のために Nil が保持されている場合は、状態に文書化された 1 つの意味を与え、それ以外の場所では拒否し、ビジネス コード全体にわたって比較を散在させるのではなく、明確に所有されている境界で変換します。
バリデータと特別な値 — 厳密なバージョン/variant チェックが Nil と Max を拒否する理由と、独自の値を使用すべきかどうかを決定する方法
ToolAcre は、1 つのバリデータ内の 2 つのレイヤーを示します。通常の入力がトリミングされ、オプションの外側の中括弧が削除され、残りの文字列が正規の 8-4-4-4-12 レイアウトと許容されたバージョンおよびバリアントの位置に対してチェックされます。 Nil はそのパターンの前にテストされ、意図的に受け入れられます。マックスも例外なく失敗します。これは、呼び出し元が正規表現だけから特別な値のポリシーを予測できないことを意味します。パターンを取り巻く制御フローは検証コントラクトの一部です。
3 つの質問に分けて独自のポリシーを設計します。まず、テキストは境界が許可する形式で認識可能ですか?次に、値は通常の UUID ですか、それとも名前付き例外ですか?第三に、そのカテゴリはこのフィールドと操作に許可されていますか?作成エンドポイントは、診断パーサーが認識した場合でも Nil を拒否する可能性がありますが、インポート境界は文書化された従来の Nil マーカーを null に変換する可能性があります。これらの結果を個別に返すことで、「パーサーがそれを受け入れました」という結果が誤って保存されることを防止できます。
ToolAcre は Nil を明示的に受け入れ、バージョンとバリアントのパターンに基づいて Max を拒否します
「未割り当て」を表す Nil を使用する担当者識別子を持つタスク テーブルを考えてみましょう。 WHERE assignee_id IS NOT NULL として記述されたクエリは、割り当てられたタスクを選択するように見えますが、センチネルは具体的な文字列であるため、すべての Nil 行も選択されます。ユーザーがそのキーを持っていない場合、結合によってそれらの行が削除され、2 番目のそれほど明白ではない結果が生成される可能性があります。どちらのクエリも局所的には妥当です。スキーマが代入を直接公開するのではなく、普通に見える識別子の中に状態を隠していたため、彼らの意見は一致しませんでした。
永続的な修正は、割り当てを割り当てとしてモデル化することです。ストレージ コントラクトで許可されている場合は null 許容関係を使用し、複数の状態を区別する必要がある場合は明示的なステータスを追加します。互換性境界が依然として Nil を送信する場合は、永続化の前に一度変換し、その境界についてのみマッピングを逆にします。次に、生成された version-4 値、Nil、Max、空の入力、および不正な形式のテキストを別のケースとしてテストします。アプリケーションは、一般的な形式チェックで返された答えを継承するのではなく、それぞれの結果を決定する必要があります。
要点: 特殊な値には明示的な処理が必要です。ToolAcre ジェネレーターを使用して実際の ID を生成し、Nil と Max を意図的な例外として扱います。
特別な値は、その形状がアプリケーションの意図を伝えることができないため、名前付きの処理が必要です。 ToolAcre は Web Crypto から通常のバージョン 4 UUID を生成し、必要に応じてrandomUUID から getRandomValues にフォールバックし、安全でないランダム ソースの使用を拒否します。そのインスペクタは、生成された値と明示的に認識された Nil 例外を区別できます。このため、このツールは観察には役立ちますが、データベース監視ポリシーを選択したり、受け入れられた識別子が既存のレコードに属していることを証明したりすることはありません。
新しい識別子のジェネレーターを使用し、すべてのセンチネルを個別のプロトコル決定として扱います。現在のチェッカーでは、Nil が有効で、バージョン 0 であり、ランダムではありません。マックスは拒否されました。ページをテストするときはその区別を維持し、どちらかの値を受け入れる前に言語、データベース、API のルールと比較してください。安全なポイントは意図的に狭いものになっています。生成された ID、パーサー例外、欠落している関係、およびビジネス状態は異なる概念であり、堅牢な境界によってそれらの違いが保たれます。