> 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
