From: Joseph Lukas
Date: July 12 2009 9:43pm
Subject: GSoC Week 10 - July 6 - July 12 | per query variable settings
List-Archive: http://lists.mysql.com/soc/407
Message-Id: <2CD374C9-D194-43A6-AAF2-4CC8174E64B9@gmail.com>
MIME-Version: 1.0 (Apple Message framework v935.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit


> KEY ACCOMPLISHMENTS LAST WEEK
This could get long sorry.  Please read fully.
Managed to over come a few walls that where encountered this week.

First was my mistake and I didn't anticipate different statements as  
was intended for the project.
I have managed to fix this in the parser. I moved from lex->var_list  
to making a new structure in the Lex called stmt_set_list this was due  
to going through the parser to see if var_list was used and in very  
remote possible statements it is therefore I determined best to use a  
separate list structure.  sql_set_variables takes a list as an  
argument and still works exactly as intended without modification.

Next I needed to anticipate other statements and decided to allow the  
parser to detect any statement and so I placed a rule for statement {}  
which should do this however due to conflicts with the  
simple_option_list I had to implement a form change and now a ':' is  
needed before the statement.

This led to the creation of the statement after the colon as  
overriding most of the lex command if I put them in.  I then decided  
to make a bool in the lex to tell if the statement was on or off.    
This was simple enough and a bool has minimal overhead.

Then in the sql_parse before mysql_execute_command makes it to the  
switch statement to execute the sql_command it checks the bool if the  
statement selector is set.  If a set statement is detected it executes  
sql_set_variables sending the new stmt_set_list and thd and properly  
manages to set the data correctly. Before executing sql_set_variables  
I needed to get the previous values to set after the statement  
execution.   This is where the implementation gets questionable.

Getting the session variables was the tricky part. First I thought  
that I could build a set_var structure with the new value but no  
functions simply return the variables value. I was using set_default  
to look at how it resets session values to the global values.  This is  
not so simple as the system_variables struct does not the same  
external variable names as are used in MySQL command line.  Example  
sort_buffer_size is actually sortbuff_size in the struct.  I still  
wanted to use the built in functions for set but need the current value.

After some frustration and miscommunication in my postings I decided  
to see how they are initialized in plugins.h and from the thd class  
itself as from the set_default functions I know session variables are  
in the system_variables struct called variables in the THD.  I was  
surprised to find that all the code seems to be is thd->variables =  
global_system_variables.  I assume then that the = sign is overloaded  
between two system_variables structs as I get confused and believe  
that you cannot simply do that without overloading.  I decided to use  
this to my advantage.  Rather than create a set of functions to go out  
and fetch a values after finding the associated names seemed overboard.

I would like to move it but at first decided to make a new  
system_variables struct as part of the lex but kept getting errors so  
I added one a temp one to the thd structure itself. That is the iffy  
part.  The way I view it was that I was putting the structure in the  
Lex anyways and it would be the same overhead. The contents is 270  
items at last check and so would not be far to excessive in memory  
when created once as the same thd is passed in all functions for the  
session.

Then this simply came down to 2 statements 1 to get the current  
variables and 1 to return them but the overloaded = makes that simple.

thd->stmt_reset_variables = thd->variables.  in order to get all the  
current session variables. While using existing functions and not  
manipulating none directly accessing any of the variables themselves.

then to return was thd->variables = thd->stmt_reset_variables.

I do not think it is really too pretty but it does work in few lines  
easy to debug and again all things re-use code functions.
The set functions seems to check for being updatable and then goes by  
variable type and determines function to call based on this.  Which  
for user sets should happen. I am not setting anything only internally  
copying current values and so checking should not be needed.
I kind of figure that the overhead would be same as you have 270 items  
you copy the values over as compared to getting the current type of  
the variable you are looking to change then looking up the variable  
location and name in the struct (*offset) and finally getting the value.

Since the 2 structs will always be the same they should not be broken  
by any future modifications to system_variables.  As noted again no  
variable is accessed directly in the copy but by the same code used to  
initialize the session variables when a new session is opened and a  
thd is created.

I think should look at the code itself I pushed it to launchpad.

This implementation seemed to get the code down to maybe 50-75 lines  
and almost all of it is from re-used functions such as the  
system_variables = system_variables and sql_set_variables.

As a note as well I wanted to do away with statement_sym but kept  
getting reduce/reduce conflicts and shift/Reduce conflicts.

So if implementation so far depending on testing issues arising the  
SET STATEMENT is fully implemented.

SET STATEMENT sort_buffer_size=1000000 : SELECT * FROM MYTEST;  so far  
works if comment out last if in sql_parse for mysql_execute_command  
you will see it sets it to 1000000.  When turned back on the value is  
reset.  Due to no SQLCOM statements for command to use any statement  
should work.

> KEY TASKS THAT STALLED LAST WEEK

Not to much for now.

> KEY GOOD VIBRATIONS

Could be relatively done.

> KEY CONCERNS

Sergei and others consider the implementation as unacceptable.  So far  
only issue could be the new thd object but need to get the original  
values some way.

> TASKS IN THE UPCOMING WEEK

Think up testing and other concerns.


PLEASE PLAY WITH THE BRANCH

launchpad:      ~jlukas79/+junk/mysql-server/

Joe