Công cụ dành cho nhà phát triển · Trình tạo UUID
UUID Nil và Max: Hai giá trị đặc biệt và thời điểm sử dụng chúng
· Lý lịch
uuid developer-workflow data-validation
Nil hoàn toàn bằng 0 UUID đã có mặt trong tiêu chuẩn kể từ 2005 và toàn F Max UUID đã tham gia 2024. Bài đăng này giải thích mục đích của chúng, cách chúng tương tác với trình xác nhận và những sai lầm về giá trị trọng điểm cần tránh.
Hàng có ID 00000000-0000-0000-0000-000000000000 — cách trình giữ chỗ trở thành lỗi sản xuất
Hàng có mã định danh là 00000000-0000-0000-0000-000000000000 có thể có hình dạng UUID trong khi mang ý nghĩa khác với mã định danh được tạo. Nếu một ứng dụng lặng lẽ sử dụng giá trị đó cho "chưa được chỉ định" thì mỗi hàng chưa hoàn thành sẽ có cùng một điểm đánh dấu. Mã giả định bất kỳ tên UUID nào được chấp nhận là một đối tượng thực, sau đó có thể yêu cầu, lưu vào bộ đệm hoặc kết hợp trên phần giữ chỗ như thể đó là một khóa thông thường. Định dạng hiển thị không truyền đạt quy tắc kinh doanh; chỉ có một hợp đồng trọng điểm rõ ràng mới có.
Lỗi sản xuất bắt đầu khi một lớp biết về phần giữ chỗ còn lớp khác thì không. Một biểu mẫu có thể gửi Nil, API có thể chấp nhận nó và một lớp lưu giữ lâu dài có thể lưu trữ nó, trong khi một nhân viên hạ nguồn coi mọi chuỗi không null là một khóa ngoại có thể sử dụng được. Thất bại không phải là Nil bị sai định dạng. ToolAcre cố tình nhận ra nó. Lỗi này khiến “văn bản hợp lệ”, “mã định danh được tạo” và “mối quan hệ được chỉ định” thu gọn thành một điều kiện không được kiểm tra.
Nil UUID — định nghĩa của nó và lý do tại sao mọi phiên bản và biến thể đều không thể kiểm tra về mặt kỹ thuật đối với nó
Trong quá trình triển khai đã kiểm tra, Nil là chuỗi hoàn toàn bằng 0 chuẩn. Nó nhận được một nhánh chuyên dụng trước khi mẫu UUID bình thường được kiểm tra, do đó isValidUuid trả về true ngay cả khi biểu thức chính quy yêu cầu một chữ số phiên bản từ 1 đến 8 và một biến thể RFC từ 8 đến b. kiểm traUuid tuân theo cùng một ngoại lệ: nó báo cáo một giá trị hợp lệ, gán phiên bản 0 và nói rằng UUID hoàn toàn là các bit 0 và không phải ngẫu nhiên. Đây là hành vi ứng dụng đã được xác minh, không phải là tuyên bố chung rằng mọi người xác thực đều phải đưa ra lựa chọn giống nhau.
Nhánh đó quan trọng vì Nil không vượt qua lộ trình phiên bản và biến thể thông thường được sử dụng cho các mã định danh được tạo. Giá trị ToolAcre phiên bản-4 mang 4 ở vị trí phiên bản và một trong 8, 9, a hoặc b ở vị trí biến thể; Nil mang số 0 ở cả hai nơi. Gọi những lần kiểm tra đó là “thất bại” mà không đề cập đến ngoại lệ sẽ gây hiểu nhầm. Trình kiểm tra trước tiên nhận ra giá trị đặc biệt, sau đó bỏ qua mẫu thông thường theo thiết kế. Người tiêu dùng cần đặt hàng rõ ràng như nhau nếu họ chấp nhận nó.
Nil UUID là một ngoại lệ hợp lệ rõ ràng trong ToolAcre, được báo cáo là phiên bản 0
Chuỗi all-f ffffffff-ffff-ffff-ffff-ffffffffffff không nhận được nhánh đặc biệt nào trong kho lưu trữ này. Nó cũng không thành công với mẫu thông thường vì f nằm ngoài phạm vi phiên bản được chấp nhận và nằm ngoài tập hợp biến thể RFC được chấp nhận. Do đó, ToolAcre báo cáo nó là không chuẩn thay vì coi nó là Không. Sổ làm việc ghi nhận lịch sử tiêu chuẩn hóa và mục đích trong ranh giới phạm vi cho Max, nhưng cả bản ghi công cụ, cách triển khai cũng như các bài kiểm tra đều không xác minh những tuyên bố đó, vì vậy bài viết này không lặp lại chúng.
Sự khác biệt này hữu ích hơn so với lịch sử không được hỗ trợ: Nil là hằng số được đặt tên có hành vi được kiểm tra, trong khi Max là đầu vào mà trình kiểm tra từ chối. Một dự án có thể xác định ngữ nghĩa trọng điểm bổ sung trong giao thức riêng của nó, nhưng lựa chọn đó không được suy ra từ ToolAcre. Nếu khả năng tương tác phụ thuộc vào việc chấp nhận một giá trị all-f, hãy ghi lại quy tắc đó và kiểm tra nó trong hệ thống sở hữu. Đừng cho rằng mọi thư viện sẽ phân loại chuỗi hình UUID giống hệt nhau.
Giá trị tối đa all-f bị ToolAcre từ chối; không có lịch sử RFC hoặc mục đích sử dụng phạm vi dự định nào được xác nhận
Giá trị trọng điểm và giá trị null chỉ trả lời các câu hỏi khác nhau khi lược đồ nói như vậy. Null có thể đại diện trực tiếp cho sự vắng mặt của mối quan hệ. Một trọng điểm giữ cho cột được điền và có thể hữu ích khi giao diện xung quanh không thể mang giá trị rỗng, nhưng nó tạo ra một giá trị trông giống như dữ liệu và do đó di chuyển qua các chỉ mục, kết nối, bộ tuần tự hóa và bộ nhớ đệm. Sự thuận tiện rõ ràng chuyển trách nhiệm sang mỗi người đọc: mỗi người phải nhớ rằng UUID được chấp nhận không nêu tên một thực thể được chỉ định.
Giao dịch đó trở thành một cái bẫy khi trọng điểm có thể đáp ứng việc kiểm tra hình dạng khóa ngoại mà không đáp ứng được ý nghĩa của mối quan hệ. Nó cũng có thể làm mờ các trạng thái riêng biệt như không xác định, cố ý không gán, xóa hoặc chưa được xử lý. Nếu những trạng thái đó ảnh hưởng đến hành vi, hãy thể hiện chúng một cách rõ ràng thay vì làm quá tải một mã định danh kỳ diệu. Trong trường hợp Nil được giữ lại để tương thích, hãy cung cấp cho trạng thái một ý nghĩa được ghi lại trong tài liệu, từ chối nó ở mọi nơi khác và chuyển đổi nó ở ranh giới được sở hữu rõ ràng thay vì phân tán các so sánh trong toàn bộ mã kinh doanh.
Trình xác thực và giá trị đặc biệt — tại sao kiểm tra phiên bản/variant nghiêm ngặt có thể từ chối Nil và Max cũng như cách quyết định xem bạn có nên làm như vậy không
ToolAcre thể hiện hai lớp bên trong một trình xác thực. Đầu vào thông thường bị cắt bớt, các dấu ngoặc nhọn bên ngoài tùy chọn bị xóa và chuỗi còn lại được kiểm tra theo bố cục 8-4-4-4-12 chuẩn cùng với các vị trí biến thể và phiên bản được chấp nhận. Nil được kiểm tra trước mẫu đó và được chấp nhận một cách có chủ ý. Max không có ngoại lệ và thất bại. Điều này có nghĩa là người gọi không thể dự đoán chính sách giá trị đặc biệt chỉ từ biểu thức chính quy; luồng điều khiển xung quanh mẫu là một phần của hợp đồng xác nhận.
Thiết kế chính sách của riêng bạn bằng cách tách ba câu hỏi. Đầu tiên, văn bản có được nhận dạng dưới những hình thức mà ranh giới của bạn cho phép không? Thứ hai, giá trị này là UUID thông thường hay một ngoại lệ được đặt tên? Thứ ba, danh mục đó có được phép áp dụng cho lĩnh vực và hoạt động này không? Điểm cuối tạo có thể từ chối Nil ngay cả khi trình phân tích cú pháp chẩn đoán nhận ra nó, trong khi ranh giới nhập có thể chuyển điểm đánh dấu Nil kế thừa được ghi lại thành null. Việc trả lại các kết quả đó một cách riêng biệt sẽ ngăn chặn “trình phân tích cú pháp đã chấp nhận nó” trở thành sự ủy quyền ngẫu nhiên để lưu trữ nó.
ToolAcre chấp nhận Nil một cách rõ ràng và từ chối Max theo mẫu phiên bản và biến thể của nó
Hãy xem xét một bảng nhiệm vụ có mã định danh người được giao sử dụng Nil cho “chưa được giao”. Một truy vấn được viết dưới dạng WHERE được giao_id IS NOT NULL dường như chọn các nhiệm vụ được giao nhưng nó cũng chọn mọi hàng Nil vì trọng điểm là một chuỗi cụ thể. Sau đó, một phép nối có thể loại bỏ các hàng đó nếu không có người dùng nào có khóa đó, tạo ra kết quả thứ hai ít rõ ràng hơn. Cả hai truy vấn đều hợp lý tại địa phương; họ không đồng ý vì lược đồ ẩn trạng thái bên trong một mã định danh trông bình thường thay vì hiển thị trực tiếp phép gán.
Cách khắc phục lâu dài là mô hình hóa sự phân công dưới dạng sự phân công: sử dụng mối quan hệ có thể vô hiệu khi hợp đồng lưu trữ cho phép hoặc thêm trạng thái rõ ràng khi phải phân biệt một số trạng thái. Nếu ranh giới tương thích vẫn gửi Nil, hãy dịch nó một lần trước khi lưu giữ và chỉ đảo ngược ánh xạ cho ranh giới đó. Sau đó, kiểm tra các giá trị phiên bản-4 đã tạo, Nil, Max, dữ liệu nhập trống và văn bản không đúng định dạng dưới dạng các trường hợp riêng biệt. Ứng dụng sẽ quyết định từng kết quả thay vì kế thừa bất kỳ câu trả lời nào mà kiểm tra định dạng chung sẽ trả về.
Bài học rút ra: các giá trị đặc biệt cần xử lý rõ ràng — tạo ID thực bằng trình tạo ToolAcre và coi Nil và Max là các ngoại lệ có chủ ý
Các giá trị đặc biệt cần được xử lý theo tên vì hình dạng của chúng không thể đáp ứng mục đích của ứng dụng của bạn. ToolAcre tạo UUID phiên bản thông thường-4 từ Web Crypto, chuyển từ RandomUUID sang getRandomValues khi cần thiết và từ chối sử dụng nguồn ngẫu nhiên không an toàn. Sau đó, thanh tra của nó có thể phân biệt giá trị được tạo với ngoại lệ Nil được công nhận rõ ràng. Điều đó làm cho công cụ này trở nên hữu ích cho việc quan sát, nhưng nó không chọn chính sách trọng điểm cơ sở dữ liệu hoặc chứng minh rằng mã định danh được chấp nhận thuộc về bản ghi hiện có.
Sử dụng trình tạo số nhận dạng mới và coi mỗi trọng điểm là một quyết định giao thức riêng biệt. Trong trình kiểm tra hiện tại, Nil hợp lệ, phiên bản 0 và không ngẫu nhiên; Max bị từ chối. Giữ nguyên sự khác biệt đó khi kiểm tra trang, sau đó so sánh nó với các quy tắc ngôn ngữ, cơ sở dữ liệu của bạn và API trước khi chấp nhận một trong hai giá trị. Điểm rút ra an toàn được cố tình thu hẹp: ID được tạo, ngoại lệ của trình phân tích cú pháp, mối quan hệ bị thiếu và trạng thái kinh doanh là các khái niệm khác nhau và các ranh giới mạnh mẽ giữ cho chúng khác nhau.