Re: [Maria-developers] GSoC weekly reports (Unique indexes for blobs)
![](https://secure.gravatar.com/avatar/0c9429b9d1450cc7d494af32f49bcae3.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/0c9429b9d1450cc7d494af32f49bcae3.jpg?s=120&d=mm&r=g)
GSoC (week 3)
Hello everyone,
I worked on InnoDB for this whole week. For each index of type
DICT_UNIQUE_HASH, an extra column is added after user defined columns and
before system defined columns.I have created new prtype(precise type) for
hash based columns.I have resolved some of the issues after debugging and
create table operation is working now.
Here is the list of main things I have done during this week.
1.added an extra hash column for each DICT_UNIQUE_HASH index
2.added an extra field in index which is mapped to hash column in a table.
3.modified some functions in row0ins.cc and row0mysql.cc to support a new
index type.
Regards,
Shubham
On 6 June 2016 at 22:57, Shubham Barai
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
wrote: 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
![](https://secure.gravatar.com/avatar/39b623a1559cf9c69ac3d9d4fb44e7fe.jpg?s=120&d=mm&r=g)
Hi, Shubham! On Jun 14, Shubham Barai wrote:
GSoC (week 3)
Hello everyone,
I worked on InnoDB for this whole week. For each index of type DICT_UNIQUE_HASH, an extra column is added after user defined columns and before system defined columns.I have created new prtype(precise type) for hash based columns.I have resolved some of the issues after debugging and create table operation is working now.
Here is the list of main things I have done during this week.
1.added an extra hash column for each DICT_UNIQUE_HASH index
2.added an extra field in index which is mapped to hash column in a table.
3.modified some functions in row0ins.cc and row0mysql.cc to support a new index type.
Good! But it looks like you still haven't started writing tests for your new features. Please do it this week, it's very important to have tests as early as possible. Regards, Sergei Chief Architect MariaDB and security@mariadb.org
participants (2)
-
Sergei Golubchik
-
Shubham Barai