5 ms·

Qb: Database toolkit for Go

90 points by aacanakin 10y ago

x5n1 10y ago
so this is more or less an orm for go? database toolkit is sort of ambiguous.
- aacanakin 10y ago
  it's like an orm but you can also build queries using builder api. It's like sqlalchemy.
- deleted 10y ago
  [deleted]
jvehent 10y ago
How does it compare to https://github.com/jinzhu/gorm/ https://github.com/jinzhu/gorm/ ?
- aacanakin 10y 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 10y 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.
    - aacanakin 10y ago
      I'm also not happy to add tons of tags in struct fields. Can you provide an example on how to do that? What I understand is to have a function inside the struct namely like "map" and define the constraints there. I think we can do this in the next milestone of qb. Can you open an issue about this? The github repo is https://github.com/aacanakin/qb https://github.com/aacanakin/qb
      - grey-area 10y ago
        I just use a function taking the row from the db in the model and creating the model from that. It avoids tags and reflection at the cost of some verbosity.
    - aodin 10y ago
      In https://github.com/aodin/sol#sol 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.
      - aacanakin 10y ago
        There is a table api in qb much like yours. See https://github.com/aacanakin/qb/blob/master/table_test.go 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.
deleted 10y ago
[deleted]
lobster_johnson 10y ago
Looks nice! Go needs libraries like these.
gtrubetskoy 10y 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 10y 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 10y 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.
- ap0 10y 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.
abritishguy 10y 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.
roadbeats 10y ago
If you're interested to see more alternatives to Gorp and Gorm, here is another one; http://github.com/azer/crud http://github.com/azer/crud

90 points by aacanakin 10y ago

x5n1 10y ago

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

aacanakin 10y ago
it's like an orm but you can also build queries using builder api. It's like sqlalchemy.
deleted 10y ago
[deleted]

jvehent 10y ago

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

aacanakin 10y 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 10y 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.
  - aacanakin 10y ago
    I'm also not happy to add tons of tags in struct fields. Can you provide an example on how to do that? What I understand is to have a function inside the struct namely like "map" and define the constraints there. I think we can do this in the next milestone of qb. Can you open an issue about this? The github repo is https://github.com/aacanakin/qb https://github.com/aacanakin/qb
    - grey-area 10y ago
      I just use a function taking the row from the db in the model and creating the model from that. It avoids tags and reflection at the cost of some verbosity.
  - aodin 10y ago
    In https://github.com/aodin/sol#sol 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.
    - aacanakin 10y ago
      There is a table api in qb much like yours. See https://github.com/aacanakin/qb/blob/master/table_test.go 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.

deleted 10y ago

[deleted]

lobster_johnson 10y ago

Looks nice! Go needs libraries like these.

gtrubetskoy 10y 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 10y 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 10y 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.
ap0 10y 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.

abritishguy 10y 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.

roadbeats 10y ago

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