[HN Gopher] Open-sourcing SQX, a way to build flexible database ...
___________________________________________________________________
Open-sourcing SQX, a way to build flexible database models in Go
Author : doylemark
Score : 81 points
Date : 2023-09-02 10:39 UTC (12 hours ago)
(HTM) web link (stytch.com)
(TXT) w3m dump (stytch.com)
| mfichman wrote:
| I like goqu (https://github.com/doug-martin/goqu), which has
| support for most SQL dialects. How does this compare?
| hankchinaski wrote:
| This looks interesting. The only db libraries I can stand are sql
| query builders. I have experienced way too much pain with orms
| over the years. They work until you have to do anything slightly
| complicated and they either get very difficult to use or very
| slow
| parthdesai wrote:
| Ecto strikes the perfect balance IMO
|
| https://hexdocs.pm/ecto/Ecto.Query.html
| 5e92cb50239222b wrote:
| It's easy to drop down to pure SQL in every ORM I've ever used.
| Meanwhile, a good ORM gives you type safe queries, and saves
| from having to write boilerplate for trivial CRUD.
|
| I honestly would like to know which ORMs most critics have
| experience with. If it's something terrible like Hibernate,
| then no wonder. For reference, the ORM I've used the most is
| Entity Framework (the new one, rewritten for NET Core), and
| it's simply wonderful for 90%+ of my work, and doesn't get in
| the way for the rest of it.
| kasey_junk wrote:
| Type safe sql is a feature of most every production quality
| db library I've used going back 20 years. You don't need the
| complexity of an orm to get that.
|
| As for trivial boilerplate, I tend to find that trivial
| boilerplate no more troubling than any of the other
| compromises orms require, whether that's polluting my data
| model with sql concerns or making me conform to db practices
| that aren't correct for my needs.
|
| And I've got extensive experience with orm going back a long
| time, including Entity Framework (which is a good orm that
| I'd still prefer not to use).
| tptacek wrote:
| I still find myself having the experience of having to unit
| test trivialities with direct SQL coding, lest I miss a
| typo, which is a (very basic) thing any ORM or query
| wrapper will tend to save me from.
| kasey_junk wrote:
| I need to do the same thing with attributes, naming
| conventions, etc that are typically required to make orms
| work.
| JodieBenitez wrote:
| > I honestly would like to know which ORMs most critics have
| experience with.
|
| I hated Doctrine. I like Django's ORM.
| ushakov wrote:
| Modern ORMs like Drizzle and Prisma can probably generate
| more safe and efficient SQL queries than you could write by
| hand in a fourth of the time and effort
| kasey_junk wrote:
| Drizzle is much closer to a classic sql builder than an
| orm. At least in my case the trouble with ORMs is mostly in
| the concept itself. Mapping sql results into objects
| defined as part of a business model.
|
| Just generating sql from native code is not an orm.
| makestuff wrote:
| You just gave me flashbacks to my first job out of college.
| It was this giant mess of hibernate with a combination of
| custom SQL queries mixed with the ORM that was responsible
| for billing data in the billions.
| dingxiong wrote:
| Yes ORM let me write plain SQL. But most time I find painful
| is the session management inside ORM. When does it decides to
| flush the query, and how it terminates an idle connection. In
| async mode, how does it add locks? When I try to customize
| the connection pool, and then all pain drives me away from
| ORM.
| pdyc wrote:
| i like xo's approach https://github.com/xo/xo but it is as is. I
| would love if something similar comes along that is used by db
| practititoners that is actively used and supported.
| jchw wrote:
| This does look like it's a little bit better than a lot of the
| other options in the Go ecosystem for database access, but this
| introduction misses something important: what SQL dialects does
| this support? It appears to be partly a wrapper around Squirrel.
| Squirrel is not new (and apparently also no longer being updated)
| but I actually have no idea which and how much of each SQL
| dialect Squirrel supports.
|
| Every time I see SQL and Go stuff, I feel literally obligated to
| introduce people to sqlc. That said, sqlc only has good support
| for PostgreSQL, and you'd have to generate code for each
| dialect... so that's something worth considering. (I still find
| it to be one of my favorite SQL tools, even with its issues.)
|
| https://sqlc.dev/
| resharpe105 wrote:
| I can atest to this. Sqlc is awesome.
| superb_dev wrote:
| SQLc is amazing, I think it should be the gold standard for SQL
| in Go
| [deleted]
| dgb23 wrote:
| I used sqlc with sqlite. The support seems fine there.
|
| In general, sqlc is very nice to use. It works well out of the
| box with a standard config. You can also override a lot of
| things.
|
| One of the nice extras about sqlc is that it doesn't feel like
| a real dependency.
|
| You don't actually include sqlc anywhere. You just use a config
| and the cli to generate Go code that relies on the std library.
| The generated code is very straight forward std Go code that
| you could write by hand.
|
| A couple of reasons to use Go in a project would be great
| support for IO, stability, great tooling, low operational
| complexity and minimal dependencies. sqlc fits nicely in there.
| zzzeek wrote:
| [flagged]
| KRAKRISMOTT wrote:
| Go has excellent ORMs
|
| https://entgo.io/ (spun out from Facebook)
| gregwebs wrote:
| We are really happy using jet. It lets you write type safe SQL
| and can read the results into structs- including joins into slice
| fields.
|
| https://github.com/go-jet/jet
| lonelyprograMer wrote:
| The best SQL query builder for Golang. Used it in 4 projects in
| production.
| [deleted]
| decohen wrote:
| Does this support loading nested models? Lack of this has been a
| huge pain point with other DB tooling for Go.
| austinpena wrote:
| SQLC released support for this recently!
___________________________________________________________________
(page generated 2023-09-02 23:01 UTC)