aboutsummaryrefslogtreecommitdiff
path: root/_posts
diff options
context:
space:
mode:
authorMelody Horn <melody@boringcactus.com>2025-03-05 00:08:32 -0700
committerMelody Horn <melody@boringcactus.com>2025-03-05 00:08:32 -0700
commite1bafb686548140c91bb6953ab1deeb62141e0da (patch)
treeb833434513ee02d25d5fe7a4d937061815e3de65 /_posts
parentc9e7b8b0cbc2c68d7049eaaf05ac0b2dcea8feeb (diff)
downloadboringcactus.com-e1bafb686548140c91bb6953ab1deeb62141e0da.tar.gz
boringcactus.com-e1bafb686548140c91bb6953ab1deeb62141e0da.zip
how did i not catch the duplicate intro there
Diffstat (limited to '_posts')
-rw-r--r--_posts/2023-02-12-uuid-versions.md6
1 files changed, 0 insertions, 6 deletions
diff --git a/_posts/2023-02-12-uuid-versions.md b/_posts/2023-02-12-uuid-versions.md
index ed652a2..9293056 100644
--- a/_posts/2023-02-12-uuid-versions.md
+++ b/_posts/2023-02-12-uuid-versions.md
@@ -10,12 +10,6 @@ sometimes you need an ID for something you are putting in the computer, so that
your database sits there going "the next post has ID 8. oh, new post? it has ID 8, okay the next post has ID 9." and all is well. except a year later you have a million posts and a bunch of people posting all at once, and every new post needs a new ID but they have to get created one at a time in the database so that they all get the right ID. If You're In Line (To Get The Next Post ID), Stay In Line. and the only way to know what the next post ID is is to check with the database, so you can't do things like save drafts offline with proper IDs. (staff probably doesn't want that anyway, but we need something vaguely similar at work, which is how i got here.) if you need to work at, say, Twitter's scale, or you need to be able to generate IDs without checking with the database, you need something more involved than just sequential IDs.
-## wait why even
-
-sometimes you need an ID for something you are putting in the computer, so that you have a stable way to refer to it even if all the editable fields on it change. the simplest possible approach is to give the first thing ID 1, the second thing ID 2, and so on. cohost works this way right now - as i'm editing it, this draft post has ID 1009270, meaning this is the just-over-a-millionth thing in the posts table.
-
-your database sits there going "the next post has ID 8. oh, new post? it has ID 8, okay the next post has ID 9." and all is well. except a year later you have a million posts and a bunch of people posting all at once, and every new post needs a new ID but they have to get created one at a time in the database so that they all get the right ID. If You're In Line (To Get The Next Post ID), Stay In Line. and the only way to know what the next post ID is is to check with the database, so you can't do things like save drafts offline with proper IDs. (staff probably doesn't want that anyway, but we need something vaguely similar at work, which is how i got here.) if you need to work at, say, Twitter's scale, or you need to be able to generate IDs without checking with the database, you need something more involved than just sequential IDs.
-
## version 1
in the early 90s, some UNIX people ran into this problem when drawing up their Distributed Computing Environment. they called [their solution](https://pubs.opengroup.org/onlinepubs/9629399/apdxa.htm) "Universal Unique Identifiers", which they call "an identifier that is unique across both space and time". it's written as a hexadecimal string, but it can be stored as just the 16 bytes that are represented by that hexadecimal string. the way they make sure it's unique across both space and time is actually pretty straightforward: part of the UUID encodes the space where it was generated, and part of the UUID encodes the time where it was generated.