4 ms·

Not to mention that sql.Result (the return value of Exec) has a LastInsertId() that's an int64, so if you're using uuids, you can't use that at all and have to

Not to mention that sql.Result (the return value of Exec) has a LastInsertId() that's an int64, so if you're using uuids, you can't use that at all and have to call Query instead and manage generated IDs yourself.

Cthulhu_ 7y ago
In a lot of cases - esp. distributed systems - it's not up to a database to generate a UUID, but the application. In theory you can have a hundred servers that generate records and send them to a central storage platform (which may or may not be a database, or event bus, etc). UUIDs are not meant to be generated by databases.
whateveracct 7y ago
Haha yes I've long since resigned myself to using Query + explicit RETURNING for inserts Cut 2 of 1000
HelloNurse 7y ago
This is a more ridiculous symptom of bad library design than the filesystem trouble mentioned by the article. In the real world, executing most SQL statement could be made to return a semi-useful integer according to simple and consistent rules (e.g. affected row count, -1 if there's no meaningful integer). But the official Go documentation https://golang.org/pkg/database/sql/#Result https://golang.org/pkg/database/sql/#Result makes it quite clear that the Go design committee decided to imitate a remarkably limited and inelegant MySQL function that returns the value of an auto-increment column, not even realizing that only a few statements have auto-increment columns to begin with. I'd call this a negative amount of design effort. LastInsertId returns the integer generated by the database in response to a command. Typically this will be from an "auto increment" column when inserting a new row. Not all databases support this feature, and the syntax of such statements varies. (Of course, MySQL's LAST_INSERT_ID() is only bad as a building block and inspiration for a general API; in SQL queries assumptions aren't a problem and overspecialized tools can be occasionally very useful)

Cthulhu_ 7y ago

In a lot of cases - esp. distributed systems - it's not up to a database to generate a UUID, but the application. In theory you can have a hundred servers that generate records and send them to a central storage platform (which may or may not be a database, or event bus, etc). UUIDs are not meant to be generated by databases.

whateveracct 7y ago

Haha yes I've long since resigned myself to using Query + explicit RETURNING for inserts Cut 2 of 1000

HelloNurse 7y ago

This is a more ridiculous symptom of bad library design than the filesystem trouble mentioned by the article. In the real world, executing most SQL statement could be made to return a semi-useful integer according to simple and consistent rules (e.g. affected row count, -1 if there's no meaningful integer). But the official Go documentation https://golang.org/pkg/database/sql/#Result https://golang.org/pkg/database/sql/#Result makes it quite clear that the Go design committee decided to imitate a remarkably limited and inelegant MySQL function that returns the value of an auto-increment column, not even realizing that only a few statements have auto-increment columns to begin with. I'd call this a negative amount of design effort. LastInsertId returns the integer generated by the database in response to a command. Typically this will be from an "auto increment" column when inserting a new row. Not all databases support this feature, and the syntax of such statements varies. (Of course, MySQL's LAST_INSERT_ID() is only bad as a building block and inspiration for a general API; in SQL queries assumptions aren't a problem and overspecialized tools can be occasionally very useful)