Hi Sergei, Hope this mail finds you well. I have asked few things as comment on my proposal that I had submitted at Melange. Can you please help me or guide me with the same ? Thanks and Regards, Kesha Shah On Tue, Mar 18, 2014 at 10:51 PM, Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Kesha!
On Mar 18, Kesha Shah wrote:
Dear Sergei Golubchik,
Hope this mail finds you well.
I am Kesha Shah, a third year undergraduate from DA-IICT, Gandhinagar, India. I was a Google Summer of Code student previous year as well as Google Code-In mentor with BRL-CAD open source solid modeling software. The activities related to my contributions at BRL-CAD at logged by me at - http://brlcad.org/wiki/User:KeshaSShah/GSoC13/Reports. My other projects can be found at - https://github.com/keshashah?tab=repositories. I have good programming hands on C and C++ and would like to take up and contribute at the Mariadb task of 'CREATE OR REPLACE, CREATE IF NOT EXISTS, and DROP IF EXISTS' [MDEV-5359] as part of GSOC 2014. I have studied database systems and compiler construction during my academics. Your project would help to apply my knowledge by working at deeper level of coding database internals, thereby contributing to open source software.
Great.
I had checked out the mariadb master branch from bazaar and started looking into the source code. I found the task more related to update of the existing mariadb SQL parser. The parser seems to be implemented as ascendant parser using bison parser generator (GNU version of YACC). From the current findings I could see the YACC grammar file sql_yacc.yy under maria/sql/ where I can see the rules defined for CREATE PROCEDURE_SYM, CREATE FUNCTION_SYM, CREATE TRIGGER_SYM etc. Alternatively I can see the *_SYM lexical tokens defined under the /maria/sql/lex.h file. Similarly for DROP TABLESPACE_SYM, DROP TRIGGER_SYM etc could be found. So when sql text input stream is encountered from SQL interface, it is read and categorized into lexical tokens by the lexer /maria/sql/sql_lex.cc in the lexical analysis step. I tried to figure out that we will have to define additional token 'IF' in the lex.h and 'NOT' and 'EXISTS' are already defined.
All three are already defined, look for CREATE TABLE IF NOT EXISTS, for example.
I am also looking at the existing user defined actions that builds the AST nodes (sp_head being the root node for most types) when relevant grammar rule is satisfied in case of DDL statements. After semantic analysis (create of stored procs/functions), the next step would be to amend/define actions for the newly introduced grammar of handling check of existence of db artefact at the time of DDL execution. Also at this step the compiler will have to query the relevant storage engine on DB level or repository level to check if the DB object exists. This would require me to spend more time on understanding design pattern followed for the implementation of classes and behaviours of each of the underlying db artefacts.
It would be interesting for me to know if the steps proposed by me above are in the right direction or not ? Also I am aware that I am
Yes, they look correct.
late in discussing my proposal with you. But I can assure that I will be able to deliver the requirements in timely manner under your guidance. I have formulated initial draft of my proposal and would like to submit it at the earliest.
Regards, Sergei
-- Kesha Shah. www.keshashah.com