Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
This came up in passing on SOLR-6741 last year, but as far as I can tell, the solr UUIDField still indexes those UUIDs as strings, not as a 128bit number.
So really, the only point of the UUIDField instead of using a StringField is that there's some validation and the possibility of a newly-generated value. Seems a little misleading.
From what I can tell, Lucene has added a bunch of support for arbitrary sized numbers and binary primitives (LUCENE-7043?), so it seems like the Solr UUID field should save some space and actually index UUIDs as what they are.
Of course, since this would change the encoding of an existing field type, it might take the form of a new "CompressedUUIDField" or something instead.