3 ms·

All of this is spot on. Go could benefit from a higher-level SQL layer, however. As an example which has been annoying me the last few days, "database/sql" doe

All of this is spot on. Go could benefit from a higher-level SQL layer, however. As an example which has been annoying me the last few days, "database/sql" doesn't automatically prepare statements; so preparing is a separate step, and if you want to use a prepared statement in a transaction, it's yet another step to convert the prepared statement to one that will work with the transaction. I have convenience wrappers around this stuff to make my SQL calls less boilerplated and more readable. It also doesn't offer high-level convenience functions for things like getting all rows mapped to structs in one go, and so on. And if you're going to support variable expansion in SQL queries, why not support named variables looked up through a map[string]interface{}? What ActiveRecord gets right, and other ORMs (Hibernate, TopLink) don't, is that you don't want to abstract away SQL. You just want to map the data from/to your native (in this case) structs, because it's convenient.

flexd 11y ago
Have you looked at https://github.com/jmoiron/sqlx https://github.com/jmoiron/sqlx It's a nice little wrapper around database/sql that offers some of the things you talk about.
- lobster_johnson 11y ago
  That's exactly what I need. Thanks!
drakenot 11y ago
It also doesn't support multiple result sets which means stored procedures which return anything are a no-go.
draaglom 11y ago
>As an example which has been annoying me the last few days, "database/sql" doesn't automatically prepare statements; so preparing is a separate step Not exactly. All the "database/sql" functions actually use prepared statements under the hood. You only need to explicitly create a prepared statement if you're reusing it (since the internal ones are also auto-closed, although I think there's also some kind of connection cache so they might be reused anyway...)
- lobster_johnson 11y ago
  > You only need to explicitly create a prepared statement if you're reusing it It does prepare statements internally, but they're not reused, which is the main point of prepared statements: I know I'll run this thing a bazillion times, so I want to prepare it once and then just execute it with new parameters from now on. As far as I can see, no caching is done [1]. There's a TODO note about maybe adding caching in the future. [1] https://golang.org/src/database/sql/sql.go https://golang.org/src/database/sql/sql.go
  - draaglom 11y ago
    Yeah, I remember reading about them planning it a couple years ago and just kinda assumed someone would've done it by now.

flexd 11y ago

Have you looked at https://github.com/jmoiron/sqlx https://github.com/jmoiron/sqlx It's a nice little wrapper around database/sql that offers some of the things you talk about.

lobster_johnson 11y ago
That's exactly what I need. Thanks!

drakenot 11y ago

It also doesn't support multiple result sets which means stored procedures which return anything are a no-go.

draaglom 11y ago

>As an example which has been annoying me the last few days, "database/sql" doesn't automatically prepare statements; so preparing is a separate step Not exactly. All the "database/sql" functions actually use prepared statements under the hood. You only need to explicitly create a prepared statement if you're reusing it (since the internal ones are also auto-closed, although I think there's also some kind of connection cache so they might be reused anyway...)

lobster_johnson 11y ago
> You only need to explicitly create a prepared statement if you're reusing it It does prepare statements internally, but they're not reused, which is the main point of prepared statements: I know I'll run this thing a bazillion times, so I want to prepare it once and then just execute it with new parameters from now on. As far as I can see, no caching is done [1]. There's a TODO note about maybe adding caching in the future. [1] https://golang.org/src/database/sql/sql.go https://golang.org/src/database/sql/sql.go
- draaglom 11y ago
  Yeah, I remember reading about them planning it a couple years ago and just kinda assumed someone would've done it by now.