GSoC (week 2)
Hello everyone,
Finally, I solved the issue with a mismatch of a key number
between sql layer and MyISAM file.I also found a simpler approach for this
with the help of my mentor.
One of the other issues that I had to deal with was compatibility issue of
key definitions between .frm file and information stored in MyISAM storage
engine. The issue was due to check_defination which compares .frm file
and MyISAM definitions of a table.The previous prototype of
check_definition didn't contain mi_uniquedef. I have modified this function
to compare mi_uniquedef.The main problem was due to the difference in
a number of keys which we pass as an argument in ha_myisam::open.
I have also started working on InnoDB.I discussed some of the
implementation approaches with my mentor. I made changes to some of the
functions in ha_innobase.cc.
Regards,
Shubham
On 31 May 2016 at 03:32, Sergei Golubchik
Hi, Shubham!
Good, thanks!
On May 31, Shubham Barai wrote:
GSoC (week 1)
Hello everyone,
After developing a prototype for MyISAM ,there were some issues to be resolved. One of the issues is related to error regarding a duplicate entry. So if there is a duplicate entry for a particular key in a row, it generates an error for another key.
After debugging, I found out that it was due to mismatch of a key number between sql layer and MyISAM file. Keys are stored in the order of user's input in sql layer. In table2myisam function, this order is changed as each key is either stored as mi_keydef or mi_uniquedef. In mi_create, for each unique definition, an extra key is created in the form of mi_keydef and stored in MYI file which creates the issue of mismatch.
I tried to solve the issue by adding extra member sql_key_no to mi_keydef and mi_uniquedef.I also modified mi_keydef_write and mi_keydef_read to support a new member but after compiling, I got some error related to a key file. Also with the help of my mentor, I found out that it could result in compatibility issues related to old MyISAM file.
So currently, I am trying to solve this using another approach.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org