[Maria-developers] GSoC 2016: Can anybody help me with a minor technical problem?
Hi everyone, I've just posted it in my blog here <http://gsocmariadbshagalla.blogspot.ru/> : Finially I finished my project on recursive CTE, so I can resume working on my project of GSOC 2016. As I said in my previous post, I decided to start with building items clones (items are used to build different kinds of expressions in MySQL). Items are typical tree structures. If I just copy a node in the item structure, pointers to the subtrees won't be right. Fortunately this pointers can be fixed in the method Item_func_or_sum::build_clone. To copy nodes we use copy constructor. As we don't know the type of the node in general the copy constructor should be virtual. I called it get_copy. It should be implemented for each terminal class of items. There are dozens of such classes. How they could be caught? I used the following trick. My get_copy for the base class Item is 'pseudo-abstract': Item *tem::get_copy(...) { dbug_print_item(this); DBUG_ASSERT(0); return 0; } Here dbug_print_item(this) helps me to understand for which class get_copy is missed. If I call now method build_clone, for example in JOIN::optimize_inner(), to build a clone for the WHERE condition, and launch tests, it'll be easy for me to understand for which classes lack implementations of get_copy. Here I've faced some minor problem: how to skip the queries that are excuted by mtr before it starts running the tests. Anybody knows? (Now I have a workaround: call build_clone() conditinally and manually trigger the condition. Of course it's not nice.) Best wishes, Galina Shalygina.
Hi, Galina! Some thoughts: 1. if you'd used a real abstract method, the compiler would've told you where you instantiate an item without get_copy() method 2. neither abstract nor pseudo-abstract method will help you in cases like Item_func_dayname and Item_func_weekday. The first is inherited from the second, and both are terminals, the first is DAYNAME(), the second is WEEKDAY() and DAYOFWEEK(). 3. Why do you want to skip queries executed by mtr? You want to be sure that they don't use items without get_copy(), so you need to test them too, not to skip them. Regards, Sergei Chief Architect MariaDB and security@mariadb.org On May 21, Галина Шалыгина wrote:
Hi everyone,
I've just posted it in my blog here <http://gsocmariadbshagalla.blogspot.ru/> :
Finially I finished my project on recursive CTE, so I can resume working on my project of GSOC 2016.
As I said in my previous post, I decided to start with building items clones (items are used to build different kinds of expressions in MySQL).
Items are typical tree structures. If I just copy a node in the item structure, pointers to the subtrees won't be right. Fortunately this pointers can be fixed in the method Item_func_or_sum::build_clone. To copy nodes we use copy constructor. As we don't know the type of the node in general the copy constructor should be virtual. I called it get_copy. It should be implemented for each terminal class of items. There are dozens of such classes.
How they could be caught?
I used the following trick. My get_copy for the base class Item is 'pseudo-abstract':
Item *tem::get_copy(...) { dbug_print_item(this); DBUG_ASSERT(0); return 0; }
Here dbug_print_item(this) helps me to understand for which class get_copy is missed. If I call now method build_clone, for example in JOIN::optimize_inner(), to build a clone for the WHERE condition, and launch tests, it'll be easy for me to understand for which classes lack implementations of get_copy.
Here I've faced some minor problem: how to skip the queries that are excuted by mtr before it starts running the tests. Anybody knows?
participants (2)
-
Sergei Golubchik -
Галина Шалыгина