lp://qastaging/~vlad-lesin/percona-server/5.6-binary-answer

Created by Vlad Lesin and last modified
Get this branch:
bzr branch lp://qastaging/~vlad-lesin/percona-server/5.6-binary-answer
Only Vlad Lesin can upload to this branch. If you are Vlad Lesin please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Recent revisions

619. By Vlad Lesin

Implement this
https://blueprints.launchpad.net/percona-server/+spec/binary-answer-5.6
blueprint.

The task can be splitted on server and client parts.

Server-side.

If we look into mysqld_stmt_prepare() function we can see the code like this:

Protocol *save_protocol= thd->protocol;
thd->protocol= &thd->protocol_binary;
stmt->prepare(...);
thd->protocol= save_protocol;

The THD class contains this members:

Protocol *protocol; // Current protocol
Protocol_text protocol_text; // Normal protocol
Protocol_binary protocol_binary; // Binary protocol

So for server-side is enough to add new command COM_STMT_EXECUTE_IMMEDIATE which
would do absolutely the same things as COM_QUERY does but with replacing
thd->protocol with &thd->protocol_binary before processing and restore protocol
pointer after processing.

Client side.

Standard C API has already have all necessary infrastructure to parse binary
protocol. So the task is to use this infrastructure. The idea is to add new
function mysql_stmt_execute_immediate() which would send
COM_STMT_EXECUTE_IMMEDIATE to server, initialize MYSQL_STMT object to use it
for parsing result with standard functions for parsing the result of
"execute prepared statement". As well mysql_stmt_bind_immediate() is necessary
to initialize certain MYSQL_STMT fields which are usually initialized inside of
mysql_stmt_prepare() and to invoke standard mysql_stmt_bind_result() function
to describe the result data.

There are two functions to execute prepared and non-prepared queries
correspondingly: mysql_stmt_execute() and mysql_real_query(). Both functions
use the same function cli_read_query_result() to get information about fields
count, their names. So this part of result parsing is the same. But rows parsing
is absolutely different.

For non-prepared query mysql_fetch_row()->read_one_row() calls just set pointers
in array of rows to the certain values in read packet. As all values are in the
text format we have the array of pointers to null-terminated strings as the
output of the function.

But when binary data are parsed in mysql_stmt_fetch()->stmt_fetch_row() the
functions use information about field types from MYSQL_STMT::bind array.
For each element of this array
mysql_stmt_bind_result()->setup_one_fetch_function() sets the pointer to the
function which parses binary data of corresponding type to the buffer. For
example fetch_result_int32() is set up for MYSQL_TYPE_LONG data type.

So we have to develop new function mysql_stmt_execute_immediate() which would
mix mysql_real_query() and mysql_stmt_execute().

Use tests/stmt_execute_immediate.cc as the source of information about the
sequence of C API calls to send query and receive and parse binary answer.

stmt_execute_immediate.cc could be the part of mysql_client_test.c but the
customer disabled this test in his tree.

The new parameter --binary-protocol is added to mysqltest to allow communication
between client and server with binary protocol without "prepare" using
mysql_stmt_execute_immedate() function to send query.

617. By Tomislav Plavcic

Null merge from 5.5 - lp:~tplavcic/percona-server/bug1328421-5.6

613. By Laurynas Biveinis

Null-merge lp:percona-server/5.5 rev 670

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
lp://qastaging/percona-server/5.6
This branch contains Public information 
Everyone can see this information.

Subscribers