My poor use of golang's defer woke me up • Hacker News Board

Re: My poor use of golang's defer woke me up

#21

Post by daemonl » Mon, Jun 23, 2014, 6:40 AM UTC

buro9 wrote: post #19

There are a couple of good resources you can use here, the first is just about the best reference for using Go with a RDBMS: http://go-database-sql.org/ The second speaks of database connections: http://jmoiron.net/blog/gos-database-sql/ The general approach: 1. Use a single DB connection, it will pool automatically 2. Use this pattern for all single row queries: err = db.QueryRow(`...`, ...).Scan(&...) if err == sql…

That's really detailed feedback, thanks for that!

I'm actually fighting with some interesting things now with error handling, I wan't aware I had to do my own retry on deadlocks.

Ugh, it's just one of those days I feel like I'm not as good at this as I thought I was.

Re: My poor use of golang's defer woke me up

#22

Post by buro9 » Mon, Jun 23, 2014, 6:52 AM UTC

daemonl wrote: post #21

buro9 wrote: post #19

There are a couple of good resources you can use here, the first is just about the best reference for using Go with a RDBMS: http://go-database-sql.org/ The second speaks of database connections: http://jmoiron.net/blog/gos-database-sql/ The general approach: 1. Use a single DB connection, it will pool automatically 2. Use this pattern for all single row queries: err = db.QueryRow(`...`, ...).Scan(&...) if err == sql…

That's really detailed feedback, thanks for that! I'm actually fighting with some interesting things now with error handling, I wan't aware I had to do my own retry on deadlocks. Ugh, it's just one of those days I feel like I'm not as good at this as I thought I was.

If you know where the deadlocks are likely to occur, consider turning to a sync.Mutex and wrapping the statement in a lock. It will cause other goroutines to wait until the lock is free.

It all depends where the deadlocks are though, you can easily achieve them in the Go code as well as the database queries.

I'm not around much today as I'm with a client this morning and lunch, but if you're stuck later I may well be in https://gophers.slack.com/ . Happy to help out if I can, as I'm sure most others will be.

Re: My poor use of golang's defer woke me up

#23

Post by pdkl95 » Mon, Jun 23, 2014, 6:55 AM UTC

seanmcdirmid wrote: post #9

randallsquared wrote: post #7

Earlier quoted context omitted.

> > but trust me, re-writing code is way easier than writing it from scratch > Not always true, and not even often true. In my experience, virtually always true. Just rereading the code you wrote before will bring back the understanding you had when you wrote it (unless you intentionally wrote obfuscated code, I suppose?), and it'll be immediately obvious to several-years-on you what the shortcomings were of that ide…

You can always take the experience , but often the old code exists in such a misguided architecture that it is better to scrap it vs. unwind multitudes of bad uninformed decisions (b.c. you know better now!). Re-writing code is actually almost always harder than writing it from scratch, but we do it for other benefits: interoperability with legacy components, legacy of expected behavior (warts and all), risk (the old…

As Brooks said, "Plan to throw one away; you will, anyhow."

There is value in a prototype - even if you don't actually use any piece of the prototype in the final product.

Re: My poor use of golang's defer woke me up

#24

Post by dagw » Mon, Jun 23, 2014, 7:02 AM UTC

pdkl95 wrote: post #23

seanmcdirmid wrote: post #9

Earlier quoted context omitted.

You can always take the experience , but often the old code exists in such a misguided architecture that it is better to scrap it vs. unwind multitudes of bad uninformed decisions (b.c. you know better now!). Re-writing code is actually almost always harder than writing it from scratch, but we do it for other benefits: interoperability with legacy components, legacy of expected behavior (warts and all), risk (the old…

As Brooks said, "Plan to throw one away; you will, anyhow." There is value in a prototype - even if you don't actually use any piece of the prototype in the final product.

If you're going to quote Brooks, it might be worth noting that he's had a slight change of heart on that point: http://www.wired.com/2010/07/ff_fred_brooks/

Re: My poor use of golang's defer woke me up

#25

Post by aktau » Mon, Jun 23, 2014, 7:25 AM UTC

buro9 wrote: post #19

There are a couple of good resources you can use here, the first is just about the best reference for using Go with a RDBMS: http://go-database-sql.org/ The second speaks of database connections: http://jmoiron.net/blog/gos-database-sql/ The general approach: 1. Use a single DB connection, it will pool automatically 2. Use this pattern for all single row queries: err = db.QueryRow(`...`, ...).Scan(&...) if err == sql…

With defers and named return values, it is actually possible to alter the return value inside of a defer. I had to do this recently to properly log an error (to abort in the calling code). Also to do with database operations of course:

https://github.com/aktau/gomig/blob/a63d309848907a72782dd94e...

It's not the prettiest, but I needed it fixed soon. Will refactor later :).

Read about it here as well: http://blog.golang.org/defer-panic-and-recover