Thanks Sergei and Nirbhay! I have managed to install Maria. Then I wanted to start working on understanding virtual columns and index in the code, and decided to run it in gdb. That was pretty tricky until I saw the page for ptrace() permission on Ubuntu. The knowledge base is pretty good :)
I put a breakpoint in the functions _mi_make_keys() and update_virtual_fields(). I then ran sql commands on the mariadb terminal to create tables with virtual persistent columns and also inserted values. At each of these, my breakpoint in the function update_virtual_fields was hit, but not at _mi_make_keys(). I Googled a bit, and saw this: MyISAM was the default storage engine from MySQL 3.23 until it was replaced by InnoDB in MariaDB and MySQL 5.5. on this page: https://mariadb.com/kb/en/mariadb/myisam-storage-engine/ I guess that MyISAM is no longer used by default and that's why breakpoint in _mi_make_keys was never hit. So I have two questions to proceed with this GSoC project: 1. In the GSoC, would we still concentrate on MyISAM? If not, can you please guide me and give me the function that constructs the key in InnoDB code? 2. I tried specifying the engine = myiasm on the terminal using this link on mysql http://dev.mysql.com/doc/refman/5.1/en/storage-engine-setting.html But this didn't help. I believe we have to change some setting in the config file? I request you to guide me to the next step. From my side, I am working hard to understand the code base and playing with it in GDB and through terminal. Thanks Richa On Sun, Mar 15, 2015 at 2:31 PM, Nirbhay Choubey <[email protected]> wrote: > > > On Sun, Mar 15, 2015 at 7:48 AM, Richa Sehgal <[email protected]> > wrote: > >> Dear Sergei and Maria community, >> >> Finally I have settled on one project: Indexing over virtual columns. >> >> I spent the entire day today trying to compile MariaDB in Ubuntu and >> reading the code. On reading code side, I spent some time in the >> /storage/myiasm/ : read fiels like mi_key.cc, mi_create.cc, ha_myisam and >> so on. Took a brief overview arounf _mi_make_key function. I also looked >> around update_virtual_fields() function. >> >> The code path is still not very clear to me - especially the transition >> point between sql folders to /storage folders. I chatted on #maria IRC and >> they gave an idea to run Maria in gdb mode. I tried compiling the code it >> was almost successful! At the very final step, I got the following error: >> >> [ 98%] Built target thr_lock >> Linking CXX shared library libmysqlclient.so >> /usr/bin/ld: error: >> /home/shikhar/mariadb/maria/trunk/libmysql/libmysql_versions.ld:155:9: >> invalid use of VERSION in input file >> collect2: ld returned 1 exit status >> make[2]: *** [libmysql/libmysqlclient.so.18.0.0] Error 1 >> make[1]: *** [libmysql/CMakeFiles/libmysql.dir/all] Error 2 >> make: *** [all] Error 2 >> >> I am not able to proceed now. I tred googling around, but could not find >> the fix. Can you please guide me in my next steps? >> > > I think you hit the ld/gold issue. > https://mariadb.atlassian.net/browse/MDEV-5982 > > Best, > Nirbhay > > >> Thanks >> Richa >> >> On Sat, Mar 14, 2015 at 10:46 AM, Sergei Golubchik <[email protected]> >> wrote: >> >>> Hi, Richa! >>> >>> On Mar 14, Richa Sehgal wrote: >>> > Thanks Sergei for the explanation. The modified project for MDEV-5199 >>> > (Table Functions) now makes sense - as in the proposals mentioned in >>> the >>> > ticket as possible solutions now looks appropriate :) >>> > >>> > I am looking into the index of virtual columns. One question: can we >>> submit >>> > proposals for 2 projects at MariaDB? >>> >>> We don't mind, but rules are set by Google, if they allow it - you can, >>> otherwise you cannot. >>> >>> > Now as for Table Functions: >>> > >>> > As mentioned there are two ways: >>> > 1. Materializing the table - this has a disadvantage for extra space. >>> > 2. Treating the UDF result as an "abstract table". For eg, the code >>> might >>> > have a base class called Table. Then we can create a derived class >>> called >>> > UDFTable and pass this instance in the regular query processing. This >>> class >>> > would implement all functionalities like Init(), Next(), Read(int >>> > col_index), Seek(), etc >>> > Consider: >>> > Select A where A.x > 10 FROM UDF_TABLE >>> > >>> > In this case, we will first construct the table UDF_TABLE through >>> regular >>> > query - evaluation of the UDF. Then we can create an instance of >>> UDFTable >>> > from the table and run normal query processing on this. >>> > >>> > Is this the right approach? Can you send me the next steps? >>> >>> the "abstract table" that can do Next, Read, Seek, etc in MariaDB is >>> represented by the "handler" class. All real storage engines inherit >>> from the handler class. >>> >>> See the SEQUENCE engine, it's in the storage/sequence/sequence.cc >>> This is, exactly, the engine that generates data on the fly, so is a >>> table function, in a sense. But it's a hard-coded function and the way >>> of passing arguments is not very nice. Still, it'll give you an idea >>> what a table function handler might look like. >>> >>> If you want an even simpler storage engines - there are some in our >>> book, "MySQL 5.1 Plugin Development". >>> >>> Regards, >>> Sergei >>> >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~maria-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~maria-developers >> More help : https://help.launchpad.net/ListHelp >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
