Qb: Database toolkit for Go

Qb: Database toolkit for Go(qb.readme.io)

90 points by aacanakin 10 years ago | 26 comments

gtrubetskoy 10 years ago |

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.

kbenson 10 years ago | |

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.

weberc2 10 years ago | | |

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.

kenshaw 10 years ago | |

We released a tool for generating Go types/funcs for databases/queries that might help you with this:

https://github.com/knq/xo

(FWIW I completely agree the added mental overhead for ORMs are not necessary)

bsaul 10 years ago | | |

Your tool is exactly what i think makes the most sense so far in having go work with DB. It's type safe (assuming the tool is correct), and doesn't add complexity in the code or complex and magic libraries.

It also makes the database schema the source of truth for a system, which makes the most sense to anyone that has really worked on complex systems (most of them having the DB be accessed by multiple subsystems, written in different languages).

cageface 10 years ago | |

The composability of queries that an ORM like ActiveRecord seems like too much of a good thing to give up. Getting the same functionality by cutting and pasting bits of SQL together is much more fragile and far less flexible. Soon enough you find yourself abstracting the various parts of the query (select columns, where clauses etc) and you're on the way to building your own ORM already.

api 10 years ago | |

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

aacanakin 10 years ago | |

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.

jasonwatkinspdx 10 years ago | |

Did you look at the above work (qb) or have any comments specific to it?

Not liking gorm or orm in general is a common enough attitude, but it feels like an unfair dismissal to not be specific about the posted library and instead criticize it based on your experience with another.

I also might have a misread here, but I doubt people are adopting query builders because they find sql hard, but rather due to combinatorial explosion in manual sql building in some application types.

ap0 10 years ago | |

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.

hellcow 10 years ago | | |

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.

whisk3rs 10 years ago | |

I generally have the same feeling, though https://github.com/go-gorp/gorp has worked very well for most of the database-heavy Go projects I've worked on over the last few years. It is just enough abstraction to be convenient and consistent and rarely gets in the way.

abritishguy 10 years ago |

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.

lobster_johnson 10 years ago |

Looks nice! Go needs libraries like these.

roadbeats 10 years ago |

If you're interested to see more alternatives to Gorp and Gorm, here is another one; http://github.com/azer/crud

x5n1 10 years ago |

so this is more or less an orm for go? database toolkit is sort of ambiguous.

aacanakin 10 years ago | |

it's like an orm but you can also build queries using builder api. It's like sqlalchemy.

jvehent 10 years ago |

How does it compare to https://github.com/jinzhu/gorm/ ?

aacanakin 10 years ago | |

The struct tags are grouped like type, constraints, etc. The groups of struct tags is more Gorm currently can't auto migrate keys with foreign keys. There is an issue I've commented but the issue is open for a long time.

There are also some missing features qb doesn't have and gorm has. For instance, you can define relationships in gorm while in qb, you can only define foreign keys using `qb:"constraints:ref(col, table)"`.

Moreover, I am not entirely sure but I don't think enforcing types is possible in gorm. In qb, consider this struct;

type User struct { id string `qb:"type:uuid; constraints:primary_key"` }

qb understands this as a uuid type although it has string definitions. These are the main reasons why I created qb.

The relationship feature is not clear in my mind. I'd like to have feedback on relationships.

grey-area 10 years ago | | |

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.