Continued from my previous post on making the SQL parser pluggable in Drizzle.
So despite mentioning that I wanted to get the prototype done by the MySQL Users Conference 09 in april, it only took three motivated days to get what I stated done. One day on code reading (grasping the execution flow), one day on hacking it, and another day on testing and debugging. If you’re interested in the outcome, you can see the branch on Launchpad.
Pushing out the SQL parser from the core was easy since all I had to do was override the mysql_parse() entry point. The only issue I came across was how MySQL is designed to execute the query inside the parser. Needless to say, this was troublesome since a given component must be completely decoupled from the system for it to be separated.
To get around this obstacle, I ended up ripping out the query execution routine from the parser and to compensate this, I introduced a new wrapper function in the Drizzle core called sql_parse_and_execute().
static void sql_parse_and_execute(Session *session, const char *query,
const size_t query_len,
const char **found_semicolon)
{
bool error= sql_parse(session, query, query_len, found_semicolon);
if (!error && !session->is_error())
{
mysql_execute_command(session);
}
clean_parsed_tree(session);
}Admittedly this solution is rough and I wasn’t 100% confident but it passed all the test cases so I pushed it to my experimental branch and threw it at the list anyway. This was a really good move since it brought up various discussions and the fundamental question of,
“is MySQL doing the right thing?”
from fellow Drizzle and MySQL developers.
As I previously mentioned, the current SQL Parser does too much by design. Ideally a parser should just create and return a Parse Tree from the query it was given. The core would then do whatever it needs to do with the tree (like create a execution plan) and free it when it’s done. Whether the execution planner should be part of the Parser Module or not is a different story of course.
The current parser is also tightly coupled with the Session object (known as THD class in MySQL) which needs to be dealt with. There are many other issues pointed out by the community and for those that are interested, you can view the thread here:
Doesn’t this show how transparent the Drizzle project is? :)
Admittedly, I’m too inexperienced at this stage to go any further on my own so I’m now planning on working closely with the veterans in the community and slowly learn as I go.
Happy Hacking!
Toru Maesaka drizzle, oss drizzle, parser, sql
