One of my colleagues inadvertantly called out a blind spot of mine today, which I am thankful for.
The problem: mapping a Mongo DB ObjectID, which is a 12 byte value to a UUID due to data type constraints in a system, in order to de-duplicate data being sent to another system.
I was initially approaching the problem from the standpoint of "translating" between the two. In other words, how can I go back and forth between the ObjectID and the mapped UUID.
My mind first went toward, "Ah geez... I'll need to standup a DB to provision the UUIID and associate it with the ObjectId bytes and lean on the DB to de-duplicate with something like:
-- enable uuid-ossp for nicer uuid functions
psql> create extension "uuid-ossp";
-- silly name, but keeping it general
psql> create table foreign_to_internal (
internal_id uuid default uuid_generate_v4(),
foreign_id bytea
primary key(internal_id),
unique(object_id)
);
-- de-duplicating insert
-- and handling conflict to return row each time
psql> insert into foreign_to_internal as t ( foreign_id ) values ('1234'::bytea) on conflict (foreign_id) do update set foreign_id = excluded.foreign_id, internal_id = t.internal_id returning *;
However, the above is much more complicated than necessary, because de-duplication is impelemented in the service for any object with an associated id.
The mapping can be accomplished by shifting from "translation" to "derivation". Through which, one can utilize a UUIDv5, instead of any of the random variants. I encourage you to read the UUID RFC and deduce when UUIDv5 is appropriate.
I had previously never considered anything outside of v4, because my problems (for however real or invented) all had to do with generating uuid's, and had never been challenged to look at anything else.
What I find interesting is, in my experience, when someone says "UUID", what they really mean is "UUIDv4", rather than alternatives.
Personally being ablew to eschew the database design and rely solely on external data to derive conformant data was a nice treat. My brain feels bigger, and my intuition is to RTFM first to see if a problem at hand can be accomplished with something unfamiliar, rather than relying on familiarity.