Ensure Prepared Statements are Used Where Necessary

[fjordan]

To ensure MySQL's plain text interface isn't used, we need to make sure this uses prepared statements. A test should be added that fails if non-prepared statements are used to query MySQL.

More context can be gathered from #44 (comment)

[fw42]

Having a test that fails as soon as you write any kind of non-prepared statement seems a bit overkill to me. Why are non-prepared statements bad in general?

What I was getting at with my comment in #44 (comment) is that this one particular query supposedly has a good reason why it's using a prepared statement (and that reason should be captured by a test). But I imagine the test itself doesn't need to know anything about prepared vs. non-prepared statements (that's an implementation detail, the same bug could probably be solved in some other way), i.e. test the interface, not the implementation.

[fjordan]

Go's MySQL driver has two protocols: 1. Plain text and 2. Binary. The binary protocol is only used with prepared statements, and allows us to know the actual type of the data being transmitted versus just being []uint8s everywhere (unless we know the schema ahead of time and can scan into the specific type).

As far as I can tell, in addition to the performance gain, we need to know the type of the data being transmitted. Are there places we shouldn't be using prepared statements? This project may warrant strictly enforcing that given its purpose, although we do query for things like read_only that obviously don't require type information.

You're right in that we should probably just test in specific places for prepared statements instead of trying to test that any interaction with MySQL is using a prepared statement. I don't think our current interface with MySQL would enable that as we'd have to wrap the driver in our own interface.

[shuhaowu]

We use multistatements to execute binlog updates. Multistatement is only usable over the text interface and not the prepared interface.

[shuhaowu]

Is this still a problem?

[fjordan]

No, I don't think it's worth tracking as an issue right now. If we change the implementation to use non-prepared statements to query data and we cannot correctly handle receiving an []interface{} then we should have plenty of tests that fail.