This part 1 of the QueryResult revamp. With this change,
vitess does not see any MySQL types. The BSON layer still
sends mysql types for backward compatibility, which will
be deleted once deprecated.
This provides translation of reult row data into native Java types.
It's a slightly different design than Cursor in the old client, which
was more like an iterator. This one is more like a JDBC ResultSet.
I didn't call it a ResultSet because it doesn't implement the full
interface.
I also switched from custom exceptions to using the SQLException
hierarchy. It should have most of the error categories we need, and if
necessary we can add new exceptions as sub-categories. That way,
managing errors and retries should be much more similar to what someone
might be used to with JDBC.
These are ported back from the new Java client tests. Now the Go tests
should be a complete reference implementation of currently available
test cases in vtgateclienttest.
As we add more test cases, we should first add a reference implementation
like this in Go, and then port the tests to other languages.
Note the hadoop java code is broken, as it uses the old
java client and not the new one (and the bson structure changed).
The right fix is probably to switch to new client there.
The previous CallerID test returns an err with a "SUCCESS: ..." message
when an sql CallerID query succeeds in order to return control to the
caller. This test needed to be updated to expect that.
Change the vtgateclienttest/services/callerid.go test to always return
an error when callerid is handled. The error will contain word
"SUCCESS:" if callerid matches. This is necessary since falling through
breaks the expectations of the caller.
In the connection's _execute_batch call, some routing will be
keyspace_ids, and some will be by shards. This means that an
_execute_batch may create both a ExecuteBatchKeyspaceIds and
ExecuteBatchShard call. Merge the results back together.
Add tests for ExecuteBatchShard in python_client_test.py and
vtgatev2_test.py.
We don't need to fork vtgateclienttest, we can just execute it
in process. The test cases are meant to be the blue print of all the
client implementation unit tests.