confusing API

[Brad Fitzpatrick]

Hello,

I've been using GoMySQL for Camlistore (camlistore.org).

GoMySQL seems to let me do anything 7 different ways, but the docs don't make it clear which subset of the total three dozen functions are used with each of the 7 or so ways.

I've used MySQL's C and Perl libraries for 10+ years so I can kinda make sense of what this Go API is trying to tell me, but the docs (despite being length) don't really tell me how to use it.

For instance, when do I need to FreeResult or Close a statement?  Can I use client.Prepare + Statement.BindParams and use {Store,Use}Result or do I need to use Execute? and FetchRow?

I want to love this library but the docs could really use some work.

As it is the MySQL state is getting wedged and I occasionally have to restart my server because each request is getting one of 3 random errors:

       #2053 Attempt to read a row while there is no result set associated with the statement

       #2000 Unknown MySQL error

       #2027 Malformed Packet

Every time I reload I get a different one of those errors.

How can I safely recycle connections into a pool?  When is it safe to reuse a connection?  What do I have to do to discard all results / cursors / misc state?

- Brad

[Denys Seguret]

I'm with you on this point. GoMySQL seems to work perfectly well (my
servers never had the slightest problem in weeks of running with about
1000 queries a day) but I'm still not sure about the best way to use the
extension (when developing I just stopped using what didn't seem to work).

I use both ways : prepared statements (not reused in my code, mainly so
that I don't have to escape params) and direct execution.If needed I can
give you links to my open source code but I'm sure other members of this
list have clearer (and validated) examples.

Le 31/05/2011 02:54, Brad Fitzpatrick a �crit :

[Phil Bayfield]

The aim of this version of the library was to attempt to offer similar functionally to the C API, the main difference from the previous version being that you can "use" or "store" a result (read one row at a time from the wire, or store all rows in memory first). It works exactly the same as the C API in this respect. I have however tweaked things a bit in ways that seemed better at the time (and hopefully are better!).

I've never personally bothered using the normal query functions, as the data return is not in a useful format, this boils down to the way MySQL returns the data.

The process for prepared statements is as follows:

• Connect
• Run the query
• Prepare
• Bind params
• Execute
• Get the data
• Bind result
• Fetch the result
• Clean up the memory (well not really as Go has GC)
• Free result

The post query functionality is a little awkward I think, the main issue being that unless the result is stored then it remains "on the wire", which means that (without implementing async calls) the library is blocked at this stage. In the previous version, the library used a mutex internally to "mimic" thread safety, however in the latest version this is removed as it is too complicated to do this.

The point at which the library is effectively blocked begins when Execute is called and ends when FreeResult is called, everything else in between can only be result manipulation functions, store, use, fetch etc.

Hope this makes sense, I'm sure the process could be streamlined, open to suggestions for this.