Comments on: Interesting findings about one of the Go database drivers for MySQL http://www.xaprb.com/blog/2012/12/28/interesting-findings-about-one-of-the-go-database-drivers-for-mysql/ Stay curious! Thu, 02 May 2013 12:36:53 +0000 hourly 1 http://wordpress.org/?v=3.5.1 By: Xaprb http://www.xaprb.com/blog/2012/12/28/interesting-findings-about-one-of-the-go-database-drivers-for-mysql/#comment-20449 Xaprb Tue, 08 Jan 2013 01:29:56 +0000 http://www.xaprb.com/blog/?p=2995#comment-20449 Thanks Julien! I noticed that you were moving. I’m following the github repo too. Thanks for the driver!

]]> By: Julien Schmidt http://www.xaprb.com/blog/2012/12/28/interesting-findings-about-one-of-the-go-database-drivers-for-mysql/#comment-20447 Julien Schmidt Mon, 07 Jan 2013 17:35:01 +0000 http://www.xaprb.com/blog/?p=2995#comment-20447 Hi Xaprb,

I’m the author of Go-MySQL-Driver.
What a nice surprise to read about it on my favorite MySQL-Blog! (Though the context might be nicer) :P

The overhead of queries without parameters is a known issue of the database/sql package. I wrote a while ago about it on golang-nuts.
I’ll propose a patch with another optional interface for Queries (Just like Execer) soon. Of course it will be implemented in Go-MySQL-Driver ASAP ;)

It’s always good to hear the thoughts of an expert. So if you notice another possible issue please feel free to share them with me via mail or at GitHub (Go-MySQL-Driver is currently moving to https://github.com/Go-SQL-Driver/MySQL), or at http://groups.google.com/group/golang-nuts if they are related to the database/sql package.

Otherwise it might take some time until I stumble upon it here on your blog :P

]]> By: Xaprb http://www.xaprb.com/blog/2012/12/28/interesting-findings-about-one-of-the-go-database-drivers-for-mysql/#comment-20446 Xaprb Mon, 07 Jan 2013 15:18:39 +0000 http://www.xaprb.com/blog/?p=2995#comment-20446 It turns out that it’s not the driver that’s surprising me, but the Go database/sql package. As this explains,

http://golang.org/pkg/database/sql/driver/#Execer

If the driver implements the optional interface, queries can be executed directly; otherwise they are prepared, executed, and then deallocated. I thought about this for a while and I think it’s a really good design. In my case it doesn’t do what I want, but it’s the best all-around design. Of course, I have the option to change the code to implement this interface, which should be quite simple, and then I should see the behavior I assumed would happen.

]]>