[FLINK-40489][table] Add UUID_V4() and UUID_V7() functions - #29154
[FLINK-40489][table] Add UUID_V4() and UUID_V7() functions#29154manner wants to merge 3 commits into
Conversation
| /** | ||
| * Holder for the {@link SecureRandom} instance, so that seeding it is deferred until a {@code | ||
| * UUID} is actually generated for the first time. | ||
| */ | ||
| private static final class Holder { | ||
| static final SecureRandom SECURE_RANDOM = new SecureRandom(); | ||
| } |
There was a problem hiding this comment.
Why a class and not just a field?
| /** | |
| * Holder for the {@link SecureRandom} instance, so that seeding it is deferred until a {@code | |
| * UUID} is actually generated for the first time. | |
| */ | |
| private static final class Holder { | |
| static final SecureRandom SECURE_RANDOM = new SecureRandom(); | |
| } | |
| /** | |
| * Holder for the {@link SecureRandom} instance, so that seeding it is deferred until a {@code | |
| * UUID} is actually generated for the first time. | |
| */ | |
| private static final SecureRandom SECURE_RANDOM = new SecureRandom(); |
There was a problem hiding this comment.
The idea was to keep the SecureRandom lazily instantiated, so it's only created when actually used (similar to java.util.UUID). But since both/all methods in the class use the RNG, the class is never loaded without needing it, so the holder doesn't help at all.
There was a problem hiding this comment.
Now that generateV4 uses UUIDs RNG, it might make sense to add this back.
github-actions
Bot
added
the
community-reviewed
| table: uuid() | ||
| description: Returns an UUID (Universally Unique Identifier) string (e.g., "3d3c68f7-f608-473f-b60c-b0c44ad4cc4e") according to RFC 4122 type 4 (pseudo randomly generated) UUID. The UUID is generated using a cryptographically strong pseudo random number generator. | ||
| description: Returns an UUID (Universally Unique Identifier) string (e.g., "3d3c68f7-f608-473f-b60c-b0c44ad4cc4e") according to RFC 9562 version 4 (pseudo randomly generated) UUID. The UUID is generated using a cryptographically strong pseudo random number generator. | ||
| - sql: UUID_V4() |
There was a problem hiding this comment.
if UUID() already generates v4, so we need a second function doing the same thing? Are they alias's - the implementation does not use the same code for each.
There was a problem hiding this comment.
The existing UUID function returns a string, while the added functions return the newly added UUID type (FLINK-40486, #29041).
| * Runtime helpers for generating {@code UUID} values, stored as their 16-byte big-endian encoding. | ||
| */ | ||
| @Internal | ||
| public final class UuidGenerationUtils { |
There was a problem hiding this comment.
Could you reconsider the purpose of this utility class now that v4 delegates to the JDK? Calling v4 also unnecessarily initializes the SecureRandom used only by v7.
There was a problem hiding this comment.
I agree. Let's move the methods to the corresponding functions and drop the UuidGenerationUtils class.
| description: Returns an UUID (Universally Unique Identifier) string (e.g., "3d3c68f7-f608-473f-b60c-b0c44ad4cc4e") according to RFC 9562 version 4 (pseudo randomly generated) UUID. The UUID is generated using a cryptographically strong pseudo random number generator. | ||
| - sql: UUID_V4() | ||
| table: uuidV4() | ||
| description: Returns a random RFC 9562 version 4 UUID value. The UUID is generated using a cryptographically strong pseudo random number generator. |
There was a problem hiding this comment.
Add "Compared to UUID, this function returns a value of UUID data type."
There was a problem hiding this comment.
Add this to all JavaDocs etc.
| table: uuid() | ||
| description: | | ||
| 根据 RFC 4122 类型 4（伪随机生成）UUID，返回 UUID（通用唯一标识符）字符串。 | ||
| 根据 RFC 9562 类型 4（伪随机生成）UUID，返回 UUID（通用唯一标识符）字符串。 |
There was a problem hiding this comment.
Only add english text here. English speakers cannot review/approve otherwise.
There was a problem hiding this comment.
This was proposed by @dylanhz in #29154 (comment).
In the existing description I only replaced the outdated RFC number.
| * Runtime helpers for generating {@code UUID} values, stored as their 16-byte big-endian encoding. | ||
| */ | ||
| @Internal | ||
| public final class UuidGenerationUtils { |
There was a problem hiding this comment.
I agree. Let's move the methods to the corresponding functions and drop the UuidGenerationUtils class.
7 participants
What is the purpose of the change
This pull request adds two new built-in SQL scalar functions,
UUID_V4()andUUID_V7(), generating RFC 9562 UUID values — a random version 4 UUID and a time-ordered version 7 UUID.Brief change log
BuiltInFunctionDefinitions.UUID_V4/UUID_V7UuidGenerationUtilswithgenerateV4()/generateV7(), producing the 16-byte internal representation of aUUIDvalue directly (no round-trip throughjava.util.UUID)UuidV4Function/UuidV7Functionruntime classesuuidV4()/uuidV7()to the Java and Scala Table API expression DSLsql_functions.yml(English and Chinese)Verifying this change
This change added tests and can be verified as follows:
UuidGenerationUtilsTest, directly asserting on the generated bytes: correct length, version nibble, variant bits, and (for v7) that the embedded timestamp matchesSystem.currentTimeMillis()at call timeUuidFunctionsITCase, covering the SQL and Table API return type (UUID) and the version nibble in the canonical string form, executed end-to-end against a MiniClusterDoes this pull request potentially affect one of the following parts:
@Public(Evolving): yes —Expressions.java(@PublicEvolving) gains two new additive methods,uuidV4()anduuidV7()UUID_V4()/UUID_V7()Documentation
sql_functions.yml) and JavaDocsWas generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Sonnet 5)