go.uuid
go.uuid copied to clipboard
satori
uuid.Value []byte vs string
Is there a particular reason why uuid.Value returns a string instead of a []byte?
I assume it's just to make it readable when storing it in a database, else you'd be storing it as a blob.
What if i want to store it as a 16 byte blob instead of a 36 byte string?
Typically, UUIDs are used as a client provided value to reference some unique record. So you'll typically receive it as a string. It makes sense to store it as such to avoid having to do any type conversion
It doesn't really matter how it is received as this library stores it in a 16 byte array. So even if I did receive it as a string from a client, it would then be a 16 byte array after calling FromString.
Point is: I can scan it from either a 16 byte slice, a text byte slice or a string. When valuing it, I should have the same options. If it came from the database as a 16 byte slice, I would assume being able to put it back like that.
Fair point. I was worried manually querying blob data in a MySQL database for example would be fiddly but it seems MySQL will cast strings to binary in queries. Not sure about other databases though...
Postgres handles this fine as well. You can exec / query with either string or byte array. On the console, it displays the UUID type as a string.
@danilobuerger @danhardman See initial discussion in #5 I never tested since if lib/pq supports binary protocol.
@satori Thanks for the link. Support for binary protocol in lib/pq was added here: https://github.com/lib/pq/pull/357. It is a bit annoying to always call Bytes(). Maybe there is a better solution while providing backward compatibility for people relying on it to be a string?
@danilobuerger What is the downside to just rolling your own struct composition and overriding Value()?
