[mbroshi]

> Did you use a regex to verify the data looks like a uuid before putting it into the database?

Is that really a thing? I have used UUIDs as primary keys many times in my life, and never had a need to do such a thing. I am struggling to even think of a valid use case.

[solumos]

> Did you use a regex to verify the data looks like a uuid before putting it into the database? Is your database (like sqlite) using a case sensitive collation for the column? Then you have a problem.

yeah, it seems like the premise is flawed. I don't know that there's actually a problem here.

[hans_castorp]

Might be related to the use of SQLite which doesn't really support data types to begin with and allows to store anything in a column regardless of the declared data type (e.g. you can store 'fourty two' in a column declared as integer).

Apparently it's a deliberate decision because they don't really want to be a "database" just something better then "a file".

[DougBTX]

Strict table support came in last year to help address this: https://www.sqlite.org/stricttables.html

[dec0dedab0de]

The only thing I can think of is if the user can export data from one system and import it to another, and for some reason there was a requirement to keep the UUIDs the same.

...or maybe if you're storing data from a remote API that uses UUID's as primary keys, and you want to make sure you catch it if they change things. Though in that case I would likely have my own primary key and store the remote primary key in a separate column