In the next YOJ minor version (2.3.0), we should introduce new FieldValueType.UUID which corresponds to a java.util.UUID value and is stored as a single column of type UTF8 (modern mapping)/STRING (legacy mapping) in YDB.
In InMemory database it will be stored as a String, to make UUID sorting consistent with YDB (Java's java.util.UUID has the weirdest compareTo() implementation possible, -100/10 don't recommend.)
This is safe because there is no existing default mapping for UUID: it currently might get detected as FieldValueType.COMPOSITE but we have no access through Java reflection because it is in the jdk.base module. Any current mapping for UUID is therefore custom, e.g. (@Column(flatten=false) for JSON mapping, or a custom value type via e.g. @StringColumn or FieldValueType.registerStringValueType()).
Existing @StringColumn and FieldValueType.registerStringValueType() conversions will just continue to work (they might be a bit more inefficient than the direct mapping, but the cost is generally negligible).
This can also be extended to support other UUID implementations in the future, e.g., newer UUID versions which Java's java.util.UUID does not generate.
In the next YOJ minor version (2.3.0), we should introduce new
FieldValueType.UUID
which corresponds to ajava.util.UUID
value and is stored as a single column of typeUTF8
(modern mapping)/STRING
(legacy mapping) in YDB. InInMemory
database it will be stored as aString
, to makeUUID
sorting consistent with YDB (Java'sjava.util.UUID
has the weirdestcompareTo()
implementation possible, -100/10 don't recommend.)This is safe because there is no existing default mapping for
UUID
: it currently might get detected asFieldValueType.COMPOSITE
but we have no access through Java reflection because it is in thejdk.base
module. Any current mapping forUUID
is therefore custom, e.g. (@Column(flatten=false)
for JSON mapping, or a custom value type via e.g.@StringColumn
orFieldValueType.registerStringValueType()
).Existing
@StringColumn
andFieldValueType.registerStringValueType()
conversions will just continue to work (they might be a bit more inefficient than the direct mapping, but the cost is generally negligible).This can also be extended to support other
UUID
implementations in the future, e.g., newer UUID versions which Java'sjava.util.UUID
does not generate.