Qb: Database toolkit for Go • Hacker News Board

Re: Qb: Database toolkit for Go

#21

Post by kenshaw » Sat, May 14, 2016, 8:34 PM UTC

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…

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)

Re: Qb: Database toolkit for Go

#22

Post by bsaul » Sat, May 14, 2016, 9:03 PM UTC

kenshaw wrote: post #21

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…

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)

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).

Re: Qb: Database toolkit for Go

#23

Post by whisk3rs » Sat, May 14, 2016, 9:04 PM UTC

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 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.

Re: Qb: Database toolkit for Go

#24

Post by idobai » Sat, May 14, 2016, 9:21 PM UTC

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…

> 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.

And what happens when someone renames a column/table? Will you replace the string everywhere? That's quite a dangerous task what I've seen to fail many times at practice. I don't like ORMs neither but I think a good compromise would be to use typesafe query generators like quill(http://getquill.io/).

Re: Qb: Database toolkit for Go

#25

Post by roadbeats » Sat, May 14, 2016, 11:52 PM UTC

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

Re: Qb: Database toolkit for Go

#26

Post by kenshaw » Sun, May 15, 2016, 12:15 AM UTC

bsaul wrote: post #22

kenshaw wrote: post #21

Earlier quoted context omitted.

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)

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, wr…

Thanks!

If you're actively using xo, I'd love to know more about how you're using it. I'm in the middle of writing up some real world examples of how to use it, and would love to be able to point to work done by others.

Re: Qb: Database toolkit for Go

#27

Post by jasonwatkinspdx » Sun, May 15, 2016, 3:23 AM UTC

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…

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.

Re: Qb: Database toolkit for Go

#28

Post by cageface » Sun, May 15, 2016, 3:40 AM UTC

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…

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.

Re: Qb: Database toolkit for Go

#29

Post by bsaul » Sun, May 15, 2016, 8:45 AM UTC

kenshaw wrote: post #26

bsaul wrote: post #22

Earlier quoted context omitted.

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, wr…

Thanks! If you're actively using xo, I'd love to know more about how you're using it. I'm in the middle of writing up some real world examples of how to use it, and would love to be able to point to work done by others.

i stopped using go because it didn't have a good enough db access library (i like using ORMs for prototyping, and then see what really needs to be recoded with direct sql later).

Not sure how you did this, but this kind of data layer generation tools were pretty common in the early C# days, you should have a look and see how they worked. The main idea is to keep a "_generated" folder independant from the rest of your code, and let people enrich your models with methods in separate files (so that you can regenerate without breaking anything). But go makes all that pretty easy, so i assume it's already the case.

Another feature is to be able to configure how many foreign relationships are queries at the same time when you request one top object, to be able to optimize db access on the most common paths.

Re: Qb: Database toolkit for Go

#30

Post by grey-area » Mon, May 16, 2016, 8:02 PM UTC

aacanakin wrote: post #7

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.

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

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.