Consider creating a UUID type and other variants of core.Id

[stewSquared]

Let's say PatientsRow.patientId is the primary key of table Patients. It has type Id[PatientsRow].

If the type that comes from the database is a serial identifier, it will be mapped to a Long, then subsequently converted to a String for Id construction. If it's a uuid, it will first be mapped to a java.util.UUID instead.

The question is, should we track the underlying type of an Id? Are two Id's the same type as long as they're of the same entitity? Even if one was made from a Long while the other was made from a UUID? Do we ever really care about the underlying implementation?

We can only convert an Id into a Long for insertion to the database if we know Long was the underlying type. Slick table definitions will remember the underlying type, so this shouldn't be a problem unless we're constructing Id values (which we shouldn't do.)