Bug: the loco generator field type uuid has sharp edges for corner cases

[joelparkerhenderson]

Loco generators provide the field type uuid which forces the UUID to be unique, but it turns out I'm discovering some sharp edges for corner cases. Here are three issues that I'm seeing in my first exploration of loco.

Issue 1. Event-oriented tables and other kinds of denormalized tables may use a field with a UUID type that's deliberately not unique. For example, imagine a table events where there's a field source with type UUID. When multiple events come from the same source, the UUID must be deliberately repeated. The real-world case is a logistics package scanner, where each physical box has a UUID label, and there's a scans table that records each time the box is scanned in transit.

Issue 2. In a totally different kind of data, I have large data sets, and enforcing a table-level uniqueness constraint takes a lot of time, especially for rapid inserts. In my case, when my app writes data, I know out-of-band that the UUID is guaranteed to be unique. As a side note, I have similar issues with web frameworks that favor PK/FK relations; in practice, I have to skip the database-layer FK constraints in favor of speed and rapid inserts.

Issue 3. In the loco docs for generator types, there's a syntax for all the fields (except uuid) where the suffix bang '!' means not nullable, and caret ^ means unique. In my opinion, it's worthwhile to make the syntax consistent for uuid. Meaning, uuid allows null, uuid! disallows null, uuid^ must be unique.