Инструменты разработчика · Генератор UUID
Nil и Max UUID: два специальных значения и когда их использовать
· Фон
uuid рабочий процесс разработчика проверка данных
Абсолютно нулевой UUID присутствует в стандарте с 2005, а все-F Макс UUID присоединился к 2024. В этом посте объясняется, для чего они нужны, как они взаимодействуют с валидаторами и каких ошибок в отношении дозорных значений следует избегать.
Строка с идентификатором 00000000-0000-0000-0000-000000000000 — как заполнитель становится производственной ошибкой
Строка с идентификатором 00000000-0000-0000-0000-000000000000 может выглядеть в форме UUID, но при этом иметь значение, отличное от сгенерированного идентификатора. Если приложение незаметно использует это значение для «еще не назначено», каждая незавершенная строка будет иметь один и тот же маркер. Код, который предполагает любые принятые имена UUID реального объекта, может затем запрашивать, кэшировать или присоединяться к заполнителю, как если бы это был обычный ключ. Видимый формат не передает бизнес-правило; действует только явный дозорный контракт.
Производственная ошибка начинается, когда один слой знает о заполнителе, а другой нет. Форма может отправить Nil, API может принять его, а уровень персистентности может сохранить его, в то время как нижестоящий исполнитель обрабатывает каждую ненулевую строку как пригодный для использования внешний ключ. Неудача не в том, что Нил уродлив. ToolAcre намеренно распознает это. Ошибка заключается в том, что «действительный текст», «сгенерированный идентификатор» и «назначенная связь» схлопываются в одно непроверяемое условие.
Ноль UUID — его определение и почему каждая проверка версии и варианта технически не проходит на нем
В проверенной реализации Nil — это каноническая строка, состоящая из всех нулей. Он получает выделенную ветвь до проверки обычного шаблона UUID, поэтому isValidUuid возвращает true, даже если для регулярного выражения требуется цифра версии от 1 до 8 и полубайт с вариантом RFC от 8 до b. InspectUuid следует тому же исключению: он сообщает допустимое значение, назначает версию 0 и говорит, что UUID имеет нулевые биты и не является случайным. Это проверенное поведение приложения, а не общее утверждение, что каждый валидатор должен сделать один и тот же выбор.
Эта ветвь имеет значение, поскольку Nil не передает обычный маршрут версии и варианта, используемый для сгенерированных идентификаторов. Значение ToolAcre version-4 содержит 4 в позиции версии и одно из 8, 9, a или b в позиции варианта; Ноль несет ноль в обоих местах. Называть эти проверки «неудачными» без упоминания об исключении было бы заблуждением. Программа проверки сначала распознает специальное значение, а затем намеренно обходит обычный шаблон. Потребителям необходим столь же видимый заказ, если они его принимают.
Nil UUID является явным допустимым исключением в ToolAcre, о котором сообщается как версия 0.
Строка all-f ffffffff-ffff-ffff-ffff-ffffffffffff не имеет специальной ветви в этом репозитории. Это также не соответствует нормальному шаблону, поскольку f находится за пределами принятого диапазона версий и за пределами принятого набора полубайтов варианта RFC. Следовательно, ToolAcre сообщает об этом как о неканоническом, а не рассматривает его как Nil. В рабочей книге Максу приписывают историю стандартизации и цель установления границ диапазона, но ни запись об инструменте, ни реализация, ни тесты не подтверждают эти утверждения, поэтому в этой статье они не повторяются.
Это различие более полезно, чем неподдерживаемая история: Nil — это именованная константа с проверенным поведением, а Max — это входные данные, которые программа проверки отклоняет. Проект может определять дополнительную семантику дозорного в своем собственном протоколе, но этот выбор не должен быть выведен из ToolAcre. Если совместимость зависит от принятия значения all-f, задокументируйте это правило и протестируйте его в системе-владельце. Не думайте, что каждая библиотека будет одинаково классифицировать строку в форме UUID.
Значение all-f Max отклоняется ToolAcre; не утверждается история RFC или предполагаемое использование диапазона
Дозорное и нулевое значение отвечают на разные вопросы только тогда, когда так указано в схеме. Null может напрямую обозначать отсутствие связи. Сигнализатор сохраняет заполненность столбца и может быть полезен, когда окружающий интерфейс не может передавать значение NULL, но создает значение, которое выглядит как данные и поэтому проходит через индексы, соединения, сериализаторы и кеши. Очевидное удобство перекладывает ответственность на каждого читателя: каждый должен помнить, что принятый UUID не называет присвоенного объекта.
Этот обмен становится ловушкой, когда страж может выполнить проверку формы внешнего ключа, не удовлетворив смысл отношения. Он также может размывать отдельные состояния, такие как «неизвестно», «намеренно не назначено», «удалено» или «еще не обработано». Если эти состояния влияют на поведение, представляйте их явно, а не перегружайте один магический идентификатор. Там, где для совместимости сохраняется Nil, придайте состоянию одно документированное значение, отклоните его повсюду и преобразуйте его на четко принадлежащей границе вместо того, чтобы разбрасывать сравнения по всему бизнес-коду.
Валидаторы и специальные значения — почему строгая проверка version/variant может отклонить Nil и Max и как решить, следует ли вам
ToolAcre демонстрирует два уровня внутри одного валидатора. Обычный ввод обрезается, необязательные внешние скобки удаляются, а оставшаяся строка проверяется на соответствие каноническому макету 8-4-4-4-12, а также принятым позициям версий и вариантов. Ноль проверяется перед этим шаблоном и принимается сознательно. Макс не является исключением и терпит неудачу. Это означает, что вызывающая сторона не может предсказать политику особого значения только на основе регулярного выражения; поток управления, окружающий шаблон, является частью контракта проверки.
Разработайте свою собственную политику, разделив три вопроса. Во-первых, узнаваем ли текст в тех формах, которые позволяют ваши границы? Во-вторых, является ли значение обычным UUID или именованным исключением? В-третьих, разрешена ли эта категория для данного поля и операции? Конечная точка создания может отклонить Nil, даже если диагностический анализатор распознает его, тогда как граница импорта может перевести документированный устаревший маркер Nil в ноль. Возвращение этих результатов по отдельности предотвращает превращение фразы «парсер принял это» в случайное разрешение на его сохранение.
ToolAcre явно принимает Nil и отклоняет Max в соответствии с его шаблоном версии и варианта.
Рассмотрим таблицу задач с идентификатором правопреемника, который использует Nil для обозначения «не назначено». Запрос, записанный как WHERE Assignee_id IS NOT NULL, по-видимому, выбирает назначенные задачи, но он также выбирает каждую нулевую строку, поскольку контрольный показатель представляет собой конкретную строку. Соединение может затем удалить эти строки, если ни у одного пользователя нет этого ключа, что приведет ко второму, менее очевидному результату. Оба запроса локально разумны; они не согласны, потому что схема спрятала состояние внутри обычного идентификатора вместо того, чтобы напрямую раскрывать назначение.
Долгосрочное решение заключается в моделировании назначения как присвоения: используйте отношение, допускающее значение NULL, если это разрешено контрактом хранения, или добавьте явный статус, когда необходимо различать несколько состояний. Если граница совместимости по-прежнему отправляет Nil, переведите его один раз перед сохранением и отмените сопоставление только для этой границы. Затем протестируйте сгенерированные значения версии 4, Nil, Max, пустой ввод и неверный текст как отдельные случаи. Приложение должно определять каждый результат, а не наследовать тот ответ, который возвращает общая проверка формата.
Вывод: специальные значения требуют явной обработки — генерируйте реальные идентификаторы с помощью генератора ToolAcre и рассматривайте Nil и Max как преднамеренные исключения.
Специальные значения требуют именованной обработки, поскольку их форма не может соответствовать целям вашего приложения. ToolAcre генерирует обычные UUID версии 4 из Web Crypto, при необходимости откатываясь от randomUUID к getRandomValues и отказываясь использовать небезопасный случайный источник. Затем его инспектор может отличить сгенерированное значение от явно распознанного исключения Nil. Это делает инструмент полезным для наблюдения, но он не выбирает сторожевую политику базы данных и не доказывает, что принятый идентификатор принадлежит существующей записи.
Используйте генератор новых идентификаторов и рассматривайте каждого дозорного как отдельное решение протокола. В текущем чекере допустим Nil, версия 0, а не рандом; Макс получил отказ. Сохраните это различие при тестировании страницы, а затем сравните его с правилами вашего языка, базы данных и API, прежде чем принимать любое значение. Безопасный вывод намеренно узок: сгенерированные идентификаторы, исключения синтаксического анализатора, отсутствующие связи и бизнес-состояния — это разные концепции, и надежные границы делают их разными.