dbwong commented on PR #1458: URL: https://github.com/apache/phoenix/pull/1458#issuecomment-1182496660
Thanks for some of the responses. I think we are talking about the same thing but let me elaborate to be clear. The UUID type is fixed length. In order to handle NULL SQL values in 2ndary indexing the type has to be rewriten to variable length type in order to write NULL. This necessitated the introduction of the concept of UUID indexable internal type. It is fine for the fixed width type to contain 0x00 in the ascending or 0xFF in the descending but not allowed in variable length type. You had an initial approach via disallowing the use of 0x00 (0xFF in desc) initially by modification of the UUID algorithm that you mentioned and thus the idea of not allowing those in the initial type but decided with the Byte[] (UUID) -> Varchar (UUID indexable) approach. Is this the correct summary? I'm okay with the risk of collision as long as it is documented. Though work by Tanuj recently around atomic upsert there would be a way to try and enforce uniqueness at upsert time but I agree it is not necessary for this feature. So I think I understand the SQL changes which is the introduction of the type and the addition of 2 consistent functions and 1 random function. 2 additional to JDBC apis plus some additional type information from metadata APIs. -------- On the desc vs ascending tests can you describe the weirdness? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
