Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Qb: Database toolkit for Go

qb.readme.io

Post reply on HN
Print view View original

11–20 of 30 posts

Re: Qb: Database toolkit for Go

#11

Post by gtrubetskoy »

I've tried gorm and in the end concluded that "orm" (in quotes because there are no "objects" in Go strictly speaking) does not make sense. Just writing out SQL statements old-school works much better, is quicker and easier to understand than the cognitive overhead of having to know yet another thing.

Also, some advice: if you're looking to abstract away from SQL because you find it hard - your time is much better spent learning a time-tested standard than yet another framework that may vanish tomorrow.

Re: Qb: Database toolkit for Go

#12

Post by aacanakin »

aodin wrote: post #9
grey-area wrote: post #6

Earlier quoted context omitted.

Have you considered another mechanism apart from field tags for relating fields to the db (for example a function for marshalling?). It's starting to look like you're creating a dsl stuffed into struct field tags as strings, which gets ugly if it is complex. This is one part of go I'm really not keen on for this reason.

In https://github.com/aodin/sol#sol I separated the table schema, which is a function, from the destination / receiver structs. This approach allows you to build tables programmatically and do condensed selections, such as all IDs into a []int. However, this process still has to match database columns to struct field names for most selections.

There is a table api in qb much like yours. See https://github.com/aacanakin/qb/blob/master/table_test.go. The session api converts tags into table object. I really like the column definitions. Maybe I can convert the definition implementation like you.

Re: Qb: Database toolkit for Go

#14

Post by kbenson »

gtrubetskoy wrote: post #11

I've tried gorm and in the end concluded that "orm" (in quotes because there are no "objects" in Go strictly speaking) does not make sense. Just writing out SQL statements old-school works much better, is quicker and easier to understand than the cognitive overhead of having to know yet another thing. Also, some advice: if you're looking to abstract away from SQL because you find it hard - your time is much better sp…

I find by far the most useful aspect of ORMs is the query builder, when done well. Much of the time I'm telling my ORM to output in core data types for speed anyway. Having a query builder that allows me to create my own methods for encapsulating common query actions is too useful to give up though.

For example: my @movies = Schema->Movie->recent->starring("brad pitt")->all;, where recent is a method to restrict movies by age, and starring is a method to join on the actors table and restrict to a specific actor.

Re: Qb: Database toolkit for Go

#15

Post by ap0 »

gtrubetskoy wrote: post #11

I've tried gorm and in the end concluded that "orm" (in quotes because there are no "objects" in Go strictly speaking) does not make sense. Just writing out SQL statements old-school works much better, is quicker and easier to understand than the cognitive overhead of having to know yet another thing. Also, some advice: if you're looking to abstract away from SQL because you find it hard - your time is much better sp…

I agree; it's a little tedious to have to write the boilerplate required, but in the end it works fine. I know exactly what queries my code is running rather than potentially being surprised by what a package/framework may be doing.

The biggest irritation I have is dealing with null values, but the built-in null types in the SQL package are adequate, and there are packages that make them play nice with JSON as well. JSON and array types in Postgres can also be a little cumbersome, but the database packages I've tried don't seem to properly handle them anyway.

Re: Qb: Database toolkit for Go

#16

Post by hellcow »

ap0 wrote: post #15
gtrubetskoy wrote: post #11

I've tried gorm and in the end concluded that "orm" (in quotes because there are no "objects" in Go strictly speaking) does not make sense. Just writing out SQL statements old-school works much better, is quicker and easier to understand than the cognitive overhead of having to know yet another thing. Also, some advice: if you're looking to abstract away from SQL because you find it hard - your time is much better sp…

I agree; it's a little tedious to have to write the boilerplate required, but in the end it works fine. I know exactly what queries my code is running rather than potentially being surprised by what a package/framework may be doing. The biggest irritation I have is dealing with null values, but the built-in null types in the SQL package are adequate, and there are packages that make them play nice with JSON as well.…

An alternative to Go's SQL null types is simply using pointers, like `*string` instead of `sql.NullString`. Pointers function in the same way, except they marshal into JSON very nicely.

Re: Qb: Database toolkit for Go

#17

Post by weberc2 »

kbenson wrote: post #14
gtrubetskoy wrote: post #11

I've tried gorm and in the end concluded that "orm" (in quotes because there are no "objects" in Go strictly speaking) does not make sense. Just writing out SQL statements old-school works much better, is quicker and easier to understand than the cognitive overhead of having to know yet another thing. Also, some advice: if you're looking to abstract away from SQL because you find it hard - your time is much better sp…

I find by far the most useful aspect of ORMs is the query builder, when done well. Much of the time I'm telling my ORM to output in core data types for speed anyway. Having a query builder that allows me to create my own methods for encapsulating common query actions is too useful to give up though. For example: my @movies = Schema->Movie->recent->starring("brad pitt")->all; , where recent is a method to restrict mov…

I've only used SQLAlchemy, but I was seriously disappointed in its query builder interface. Building SQL queries seems like something that should be straightforward, but SQLAlchemy seems to throw Python magic at every thing, making the API very difficult to reason about. Worse, the documentation is very difficult to locate and navigate through. :(

I suspect this is particular to SQLAlchemy, but if not I'd prefer just to roll my own SQL going forward.

Re: Qb: Database toolkit for Go

#18

Post by aacanakin »

gtrubetskoy wrote: post #11

I've tried gorm and in the end concluded that "orm" (in quotes because there are no "objects" in Go strictly speaking) does not make sense. Just writing out SQL statements old-school works much better, is quicker and easier to understand than the cognitive overhead of having to know yet another thing. Also, some advice: if you're looking to abstract away from SQL because you find it hard - your time is much better sp…

In the early days, qb has only the builder api. However, I also wanted to have a table builder from structs. Currently, the builder has completely separate implementation from session. The session is the structural composition of builder, engine, metadata, etc. You can see more examples in https://qb.readme.io/docs/the-builder

Feedbacks & Contributions are welcome about the builder.

Re: Qb: Database toolkit for Go

#19

Post by abritishguy »

When I read the title I thought this would be a toolkit for writing databases.

A lot of the work involved in writing a database is systems stuff such as being sure that a commit log has actually been committed. Having a toolkit that does all that stuff for you would make it a lot easier to write your own database.

Re: Qb: Database toolkit for Go

#20

Post by api »

gtrubetskoy wrote: post #11

I've tried gorm and in the end concluded that "orm" (in quotes because there are no "objects" in Go strictly speaking) does not make sense. Just writing out SQL statements old-school works much better, is quicker and easier to understand than the cognitive overhead of having to know yet another thing. Also, some advice: if you're looking to abstract away from SQL because you find it hard - your time is much better sp…

I've abandoned ORMs everywhere. SQL is easy and abstraction layers tend to make easy things slightly easier but harder things much harder.
Post reply on HN