Use v4 UUID instead of v1 for query cacheKey#451
Conversation
This uses a purely random v4 UUID instead of a time-based v1 UUID for the query cacheKey (which were initially introduced in 84aae81). v1 UUID are based on current time and the hardware MAC address of the machine where they are being generated (although the implementation in the npm uuid module uses generates a random fake MAC address). As such they have much more complex semantics than v4 UUIDs which are simply randomly generated. Unless there's a specific requirement for the special semantics of v1 UUIDs it is simpler and less error prone to simply go for v4 UUIDs whenever just a unique identifier is needed.
|
Hi @ctavan! Thanks for your work on the uuid module and this PR! The use here definitely doesn't require v1 UUIDs. v4 would be just fine. As for my original motivation for using v1 here -- that was out of habit to be honest. I used to use a lot of SQL Server where clustered primary keys are sometimes recommended to use v1 UUIDs instead of v4 in order to better fill data pages (https://docs.microsoft.com/en-us/sql/t-sql/functions/newsequentialid-transact-sql?view=sql-server-2017) So for a while my thought process was... do I need the pure randomness or is a time sequenced value okay? ... with v1 being a default out of consideration for the db index 😅 Since the embedded db SQLPad uses doesn't benefit from v1 at all, and it is generated in the browser and not on the db itself, v4 is the more appropriate UUID to use here. |
This is very valuable and insightful feedback, thank you! And also thanks a lot for the quick response and for accepting my patch, greatly appreciated! |
2 participants
I'm a co-author of the uuid npm module which is being used in some places within the code base of sqlpad.
I'm currently trying to understand real-world use cases of time-based UUIDs ("v1 UUIDs").
I found one occurrence where v1 UUIDs were being used instead of v4 UUIDs and I was wondering if this case really requires the semantically much more complex v1 UUIDs or whether we could live equally well with purely random v4 UUIDs?
I'd be really curious to understand the motivation for choosing v1 over v4 UUIDs in the first place, so any feedback on this would be highly appreciated!
@rickbergfalk, as far as I can tell from the git history you introduced this in 84aae81, I'd be really curious about your feedback!