I notice the commits are regular uuids on /dev/null.
To go even further with the git metaphor, what if we considered transitioning to content-addressed SHA-1 hashes like git does? Could also be a cool/clever way to approach editing commits etc if the feature ships later.
What…
Commit
1afe26c
can you explain this content-addressed SHA-1 hashes?
On GitHub, commits usually look like e83c5163316f89bfbde7d9ab23ca2e25604af290. Unlike uuids on here (https://dev-null.sh/@kachelle/commits/01a1563d-fe17-70ec-af96-4d137aa047b4) that are arbitrary, git essentially creates the id if your commit by hashing your data. Basically a…
/dev/nullKjell Kind (@kachelle) replying to @mathcrln on /dev/null: “can you explain this content-addressed SHA-1 hashes?”can you explain this content-addressed SHA-1 hashes?
Downside would be that uuidv7 is time sorted and sha hashes are not. So that'd make the primary key inefficient for indexing.
commit 1afe26c
Agreed, but uuidv7 could still stay the primary id (and it would likely be necessary to manage all the redirects for existing publications). The sha hashes would just be for the public identifiers and can be indexed normally.
Although yes they would likely be heavier to store,…