uuid.Value []byte vs string about go.uuid HOT 9 OPEN

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

from go.uuid.

I assume it's just to make it readable when storing it in a database, else you'd be storing it as a blob.

from go.uuid.

What if i want to store it as a 16 byte blob instead of a 36 byte string?

from go.uuid.

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.

from go.uuid.

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...

from go.uuid.

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.

from go.uuid.

@danilobuerger @danhardman See initial discussion in #5
I never tested since if lib/pq supports binary protocol.

from go.uuid.

@satori Thanks for the link. Support for binary protocol in lib/pq was added here: lib/pq#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?

from go.uuid.

@danilobuerger What is the downside to just rolling your own struct composition and overriding Value()?

from go.uuid.