read_query() function is called once
for each query submitted by the client and accepts a single
argument, the query packet that was provided. To access the
content of the packet, you must parse the packet contents
For example, you can intercept a query packet and print out the contents using the following function definition:
function read_query( packet ) if packet:byte() == proxy.COM_QUERY then print("we got a normal query: " .. packet:sub(2)) end end
This example checks the first byte of the packet to determine
the type. If the type is
Server Command Constants),
we extract the query from the packet and print it. The structure
of the packet type supplied is important. In the case of a
COM_QUERY packet, the remaining contents of
the packet are the text of the query string. In this example, no
changes have been made to the query or the list of queries that
will ultimately be sent to the MySQL server.
To modify a query, or add new queries, you must populate the
query queue (
proxy.queries), then execute the
queries that you have placed into the queue. If you do not
modify the original query or the queue, the query received from
the client is sent to the MySQL server verbatim.
When adding queries to the queue, you should follow these guidelines:
The packets inserted into the queue must be valid query packets. For each packet, you must set the initial byte to the packet type. If you are appending a query, you can append the query statement to the rest of the packet.
Once you add a query to the queue, the queue is used as the source for queries sent to the server. If you add a query to the queue to add more information, you must also add the original query to the queue or it will not be executed.
Once the queue has been populated, you must set the return
read_query() to indicate
whether the query queue should be sent to the server.
When you add queries to the queue, you should add an ID. The ID you specify is returned with the result set so that you identify each query and corresponding result set. The ID has no other purpose than as an identifier for correlating the query and result set. When operating in a passive mode, during profiling for example, you identify the original query and the corresponding result set so that the results expected by the client can be returned correctly.
Unless your client is designed to cope with more result sets than queries, you should ensure that the number of queries from the client match the number of results sets returned to the client. Using the unique ID and removing result sets you inserted will help.
read_query_result() function are used in
conjunction with each other to inject additional queries and
remove the additional result sets. However,
read_query_result() is only called if you
populate the query queue within
Copyright © 1997, 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices